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ABSTRACT 


During  the  iy£es  we  will  continue  to  see  en  increased 
use  of  distributed  corputer  neti*crks.  Although  network 
usage  has  been  found  to  be  effective  in  a  wide  variety  of 
applications,  continued  network  expansion  heightens  the  need 
for  effective  management  tc  acnieve  cptimum  performance, 
reliability,  and  security  of  network  operations.  Advances 
in  network  management  have  rot  kept  pace  with  the  problems 
that  arise  in  network  operation.  The  Corrrrunity  Cn-Line 
Intelligence  System  (COINS)  is  a  packet-switched  network 
connecting  organizations  in  The  U.S.  intelligence 
ccrrn.ni  ty .  COINS  eihit:its  rrany  of  the  difficulties  faced  by 
large  networks.  It  is  ironic  that  networks  have  made 
advanced  technology  available  to  a  large  Lumber  of  users, 
yet  the  use  of  aavanced  technology  to  assist  network 
Fana^erent  has  been  relatively  iirited.  This  thesis  will 
study  the  CCINS  Network  Control  Center  (CNCC)  and  explore 
vays  that  Voice  Input/Cutput  (VIO)  Technology  can  be  used  to 
improve  the  dey-to-day  managernent  of  network  operations. 
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I.    INTxiODlCTION 



A  central  lechnoiogicai  iheire  of  liie  197Zs  was  the 
coupling  of  tvo  techncl  cgies  :  computing  and  corrmunice  t  ions  . 
Drarratic  reduction  in  the  cost  of  digi  tal-tecnnoiogy  and  a 
less  dramatic,  cut  still  sizeable,  expansion  of  date 
transmission  capabilities  have  spurred  the  introduction  and 
growth  of  several  geographically  distributed  computer 
networlfS.  Pioneered  ty  a  combination  of  government  research 
and  private  initiative,  computer  networks  are  becoming 
increasingly  available  for  a  wide  variety  of  applications. 

The  essential  characteristic  of  a  computer  network  (or 
more  properly,  a  computer  comm.unicat icns  network)  is  that 
the  user  views  the  network  as  a  collection  of  computing 
resources  that  provide  a  range  of  diverse  services  and 
capabilities  [Ref.  1:  p.  1^10].  These  computational 
resources  are  accessible  to  users  through  a  network 
architecture  that  is  more  or  less  transparent.  In  most  of 
today's  networks,  tne  user  must  establish  a  logical 
connection  to  one  of  the  network  computers  end  use  a  set  of 
host-dependent  commands  to  access  and  uanipulate  data. 
Networks  of  the  future  are  likely  to  to  become  increasingly 
transparent  in  the  sense  that  the  user  will  view  the  entire 
netvorK  ,ard  connected  networks)  as  a  single  black  box  that 
provides   a  set  of  information  processing  resources  that  can 
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be  accessed  by  a  conrirr,cn  corrrana  and  query  laTiguage.  Figure 
1  iiiustrates  the  user's  view  cf  a  preseni-day  ccmputer 
corriruni  cat  ions  network. 

Much  of  the  wcrij:  in  advancing  netvcric  technclogy  has 
been  spearheaded  by  The  Advanced  Research  Projects  Agency 
(ARFA)  ol'  the  Eepartnrent  ci'  Defense  (DcD).  The  ARPANET,  an 
experimentci  network  erploying  pacK:et-swi  tching  technology, 
has  teen  operational  since  lyey.  This  network  connects  over 
fifty  host  computers  at  mere  than  forty  different  locations. 
This  geographical  dispersion  is  accorpanied  ty  consideracle 
diversity  in  the  types  of  computers  thct  serve  as  host 
machines.  In  addition  to  its  ov^n  networking  activities,  the 
ARFA  technology  ha?  influenced  a  number  of  ether  distributed 
information  processing  projects  both  within  EoD  and  in  other 
government  agencies.  One  cf  these  efforts  was  the  Community 
Cn  Line  Intelligence  System  (COINS)  which  interconnects  on- 
line information  storage  ana  retrieval  systems  located  at  a 
number  of  locations  \»ithin  the  U.S.  intelligence  community. 

As  with  Tiany  areas  cf  advanced  technology,  the  technical 
problems  of  computer  networking  nave  been  solved  fairly 
easily;  the  problems  cf  netwcrK  management  and  control  have 
been  a  good  deal  less  tractable.  It  is  ironic  that  the 
control  mechanisms  for  ccmputer  networks,  which  embody 
advanced  AD?  and  communications  technology,  are  generally 
rather  primitive.  The  COINS  NetwcrK  Control  Center  (CNCC), 
for   example,   has   several  serious  limitations  in  hardware, 
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physical  ccnneciicn 
logical  connection 


ji^eure   1.      User's    Viev    of    a  Corr.piiter-Corrrunications   Network 

(Reprinted   from   Reference   1; 
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software,  and  in  operator  assistance.  The  purpose  of  this 
thesis  is  to  study  the  existing  CNCC  and  to  explore  ways 
that  Voice  I npi.t/ Output  (VIC)  technology  iright  be  used  to 
help  the  CNCC  operators  better  manage  the  networlc.  To 
assist  in  this  process,  we  have  designed  and  itrplenented  a 
cor^puter  simulation  cf  the  CNCC  to  help  us  study  the 
applicability  and  feasibility  of  voice  technology. 

We  will  first  descrioe  the  COINS  Network  and  the  CNCC. 
We  will  then  sumr.arize  some  of  the  advances  in  VIO 
technology  ever  the  last  several  years  and  analyze  the 
extent  to  which  the  technology  is  likely  to  improve  the  CNCC 
operation.  We  will  then  descrioe  the  design  of  the  CNCC 
computer  model  and  present  some  preliminary  conclusions  that 
were  obtained  by  using  it.  lastly,  we  will  discuss 
implementation  strategies,  costs,  and  potential  pitfalls 
associated  with  installing  VIO  in  the  CNCC. 
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II  .   THE  COINS  NETWORK 

A.   BACKGRCUNE 

The  Ccrmuniiy  Cn  Lire  Inteiiigence  System  grew  cut  cf 
the  need  for  U.S.  intelligence  agencies  to  share 
inf  crnfat  icn.  COINS  I  originated  as  a  star  network  with  a 
resscge-swi  tcning  corr.puter  in  the  star's  logical  center  at 
NSA.  In  the  early  days  of  COINS  I  operation,  the  switch 
corrpiiter  served  as  a  ae  facto  Neiworic  Control  Center  because 
ail  traffic  was  routed  through  it  enabling  it  to  rronitor  the 
status  of  the  network  [Ref.  2:  p.  3-i] .  COINS  II,  developed 
in  the  rrid-lb73s,  uses  the  ARFA  packet-switching  technology 
to  connect  its  host  computers.  There  is,  tnerefore,  no 
longer  a  central  iressage-switcb  to  perforir  the  network 
control  function. 

The  current  network  consists  of  several  host  systems 
(sorre  of  which  are  served  by  PDP-11  front-end  processors). 
Hosts  are  connected  to  the  network  by  Interface  Message 
irocessors  (ir'.Ps)  interconnected  by  wideband  corrrunicat ion 
lines.  The  II^Ps  forTi  a  reliable  and  secure  corrminicat  ions 
subnetwork  which  uses  a  variety  of  techniques,  such  as 
adaptive  routing,  to  ensure  network  perforTiance  and 
cvaliabiiity . 

During  a  typical  CCIi^S  operation,  a  user  at  a  terminal 
connected   to   sore  host   (or   alternatively   to  a  Terrr.inal 
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Access  S/stem  (TAS;)  enters  an  inierrc^ati on  request  for 
retrieval  of  informetion  that  resiles  at  sorre  other  networK: 
host.  The  retrieval  request  is  i-assed  frorr;  the  host  to  its 
ll^F  vhere  it  is  divided  into  pacKets  approxirrately  1000  bits 
long.  These  packets  are  independently  routed  through  the 
netVfCrij:  until  they  arrive  at  the  destination  II^iP  where  they 
are  reassembled  into  the  cri^-inal  interrogation  message. 
After  reasser-tly,  the  destination  ir'?  passes  the  request  to 
its  host  computer  for  action.  The  destination  host 
processes  the  interrogation  by  retrieving  and  forratting  the 
requested  data  from  its  files  and  passing  the  answer, 
tnrough  the  networK,  bacK  to  the  requesting  terminal  [Ref  3: 
p.  1-3].  COINS  hosts  provide  a  variety  of  query  languages, 
file  structures,  networit  protocols,  and  terjrinal  types. 
Additionally,  The  COINS  Project  f^anagement  Office  (COINS 
F^C )  actively  develops  hardware  and  software  corponents  to 
facilitate  the  smooth  and  rapid  exchange  cf  information 
between  users  on  diverse  nosts.  The  Technology  Transfer 
Research  facility  (TTRF),  a  part  of  the  COIN'S  P^0,  is 
actively  involved  in  projects  such  as  the  EARPA-sponsored 
r-an-r^achine  Relationship  Program  and  the  development  cf  a 
multiple  retrieval  language  translator  (called  ADAPT)  which 
IS  intended  to  serve  as  a  commoa  user  interface. 
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2.      MTWOEK    CCMIGURATICN 

Conceptuaiiy,    ihe   COINS    II      network      can      iDe     vieved      as 
ccnsisiing      ci"      four    independent;    layers    cr    rings    as    shewn    in 
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gure  2.    The  Host   ring  consists   of   relatively   large 


corrputers  thai  support  on-line  data  cases  and  provide  direct 
analytic  support  to  intelligenct  analysts.  Ixarrples  include 
the  SISINT  Cn-line  Ini'crrrat  ion  System  (SOUS)  at  KSA  and  the 
UNIViiC-lll?  system  at  the  National  Photo  Intelligence  Center 
(N?IC/.  The  Access  prccesscr  Ring  consists  cl'  various 
corputer  systerrs  that  allow  a  user  to  access  COINS  data 
cases  without  going  through  a  host.  Included  in  this  layer 
are  the  Terrrinal  Access  Systerrs  (TAS)  which  are  roughly 
analcgcus  tc  very  high-powered  TIPs  in  ARPANET  tern^inolcgy? 
Front-Ini  Processors  (FIPs)  which  connect  hosts  to  the 
corrun icat icns  sucnetwcrk;  and  Gateways,  which  serve  as 
interfaces  oetween  COINS  II  ana  other  networks.  The  IMP 
ring  is  the  cornunicat icns  subnetwork  cased  upon  ARPANET 
philosophy  and  technology.  The  Tl  (tetrahedron)  ring  is 
that  activity  mat  links  the  IMPS  together  and  maintains  the 
secure  ccrrunica tions  of  the  COINS  II  network:  [fief.  4:  p. 
4-5]. 

In  rigure  3,  which  portrays  the  current  COINS  II 
topology,  the  inaependent  layers  are  denoted  ty  different 
syrrccis:  hosts  are  represented  by  rectangles?  access 
processors  ty  triangles;  and  IMPS  ty  circles.  Figure  3 
highlights  the  fact  that  COINS   II   is  a   true  distributed 
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Figure  2.  Conceptual  View  of  Coins  II 
(from  Reference  2) 
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figure  3.  COINS  II  Neiwcric  Heference  Map 
(frorr  Reference  2) 
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network  vitii  functions  allocated  both  to  individual  layers 
and  to  Individual  coFipcnents  on  the  sarre  layer.  This 
provides  greater  reliability  and  flexibility  since  the 
net^crk  can  continue  to  operate  in  the  face  of  host,  IMP,  or 
ccrrtrunicaticn  line  failures.  A  key  feature  of  the  network 
IS  the  use  of  an  aaaptive  routing  aigorithrr  to  pass  [messages 
:"rcrr  I.'-IP  to  If'P.  Each  IMP  is  connected  tc  at  least  two 
neighbor  IMPs.  At  tne  tirre  an  IMP  receives  a  rressage  fron: 
its  host,  it  ieciaes  the  proper  route  tc  use  to  deliver  the 
ressage  to  its  destination  based  on  the  current  state  of  the 
netvcrk.  For  eiarple,  to  route  a  nessage  frorr  IMP  1  to  IMP 
£,  there  are  three  lires  fron  which  to  choose.  N'orrrelly, 
the  direct  line  (line  1)  would  be  the  best  approach.  If  IMP 
1  detects  that  line  1  is  either  down  or  heavily  loaded,  it 
can  choose  tc  route  the  ressage  indirectly  over  two  other 
possible  routes. 

C.   NZTVkCHi.  MANAGZMENT  AND  CCNTRCI 

Management  of  a  computer  network  encompasses  all  facets 
of  operation  including  long-range  planning,  training, 
staffing,  and  oudgeting.  In  this  paper,  however,  we  will  be 
primarily  concerned  with  day-to  day  management  and  control 
cf  network  resources.  The  chief  prerequisite  for  effective 
operational  control  is  the  ability  to  rapidly  diagnose  and 
respond  tc  failures  in  the  netwcrk.  These  functions  are 
performed  bj    the  COINS  Network  Controller  who  uses  the  COINS 
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.\ei;\»crK  Control  Cenier  (CNCC)  computer  to  assist  in  the 
rronitoring  and  control  of  the  network.  The  CtXC  and  the 
Controller  will  te  discussed  in  greater  detail  in  the  next 
section.  Before  doing  so,  however,  we  will  point  out  some 
of  the  general  protlerrs  of  controlling  a  distributed  network 
end  discuss  sone  of  the  longer  range  plans  for  COINS  network 
nanagerrent . 

The  COINS  ccmmunicat  ions  subnetwcrn:  can  be  considered  a 
distributed  computation  system  [Ref.  3:  p  1-5],  since 
message/packet  processing,  network  status  rrcnitcring,  and 
trouble  reporting  are  performed  independently  by  each  IMP. 
This  distribution  of  function,  while  ensuring  better  overall 
reliability  and  service,  does  complicate  the  problem  of 
detecting  ana  correcting  probienis  with  network  components. 
Geographical  distribution  further  aggravates  the  control 
problem.  The  CNCC  was  established  to  address  the  problems 
cf  distributed  ccrtrol.  It  serves  the  multiple  functions  cf 
continually  monitoring  and  diagnosing  problem  areas, 
coordinating  corrective  measures,  and  providing  a  central 
point  to  which  users  may  direct  inquiries  and  complaints. 
Each  ir-iP  is  programmed  to  examine  itself  and  its  interfaces 
perioaically  and  report  the  results  to  the  CNCC.  The  CNCC 
collects  these  (possibly  conflicting/  IMP  reports, 
ceterrines  the  most  likely  true  state  of   the   network,   and 
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sufegesis   tne   requirea   repair  activiiy   in   the   event  of 
reported  failures. 

The  CCINS  Ft^O  is  piannirg  to  implement  a  fully  autcrrated 
on-line  systeir  for  the  collecting,  editing,  analyzing,  and 
reporting  cf  netvcrx  information.  The  infcrrraticn  will  te 
usei  to  [Tonitor  the  operations,  p  erf  orrpance ,  and  utility  of 
the  CCINS  Network.  This  effort,  known  as  the  COINS  Network 
^,enc5ement  System  (CNf^S),  is  planned  to  be  irplemented  in 
stages  over  the  next  five  years.  This  paper  is  intended  to 
corplement  that  effort  by  exploring  some  remedial  steps  that 
can  be  taken  to  irprove  the  performance  of  the  existing  CNCC 
that  later  coula  be  incorporated  into  the  enhanced  CNMS . 


22 


Ill  .   "yKS  ecus  NETWORK  CCNTECL  CENTER 

A.   CONFIGURATION  AND  FUNCTIONS 

As  noted  atove,  ihe  CNCC  rraintains  a  dynarric  piciure  of 
the  siatiis  of  ail  network  components  (IMP's,  FEPs  ,  INIs,  and 
lines)  and  is  thus  able  to  direct  recovery  prccedures  in  the 
event  of  component  failures.  The  CNCC  trachine,  a 
Honeyvell-316  computer,  is  attached  to  the  subnetwork  by 
means  of  a  local  host  connection  to  the  netwnric's  master  IMP 
( I^*P  1).  The  operation  of  the  remote  IMPs  can  be  controlled 
either  from  the  CNCC  or  directly  from  the  Master  IMP.  The 
Control  Center  operator  is  responsible  for  both  machines. 

The  CNCC  uses  twc  teletypes  (Icncwn  as  the  logger  TTT  and 
the  Summary  TTY)  as  primary  output  devices.  The  system  uses 
the  Logger  to  print  event-oriented  messages  as  they  occur. 
Logger  messages  are  often  concerned  with  alert  information 
pertaining  to  the  status  of  network  ccmponents  and  will 
frequently  require  action  by  the  NetworK  Controller.  The 
CNCC  has  an  alarm  dox  wired  into  the  logic  of  the  Logger  TTT 
which  keys  on  the  presence  of  a  sentinel  charccter  (ASCII 
contrcl-G  or  BILL]  in  a  Logger  message.  Thus,  by  changing 
the  teit  of  the  Logger  messages,  any  message  can  be  made  to 
set  off  the  alarm  box  and  alert  the  operator.  The  Summary 
teletype  is  used  to  print  periodic  reports  and  also  serves 
as  the  primary  corrrand  input  device  for  the  CNCC   operator. 
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The  CNCC  can  also  communicate  with  ether  COINS  hosts  such  as 
the  UNIVAC  494  host  at  N3A.  These  host-to-host 
communications  are  used  primarily  to  transfer  networlc  status 
end  summary  files  for  further  processing  and  reporting.  One 
of  the  fundamental  otjectives  of  this  thesis  is  to  evaluate 
the  use  of  voice  input  technology  to  perform  the  input 
function  of  the  Surrmary  TTY  and  voice  output  technology  to 
perform  the  acticn-alert  function  of  the  Logger  TTY. 

The  CNCC  program  is  driven  by  three  sources:  (l)  reports 
from  the  netvcric  IMPs ,  (2)  a  real-time  clock:,  and  (3;  input 
conrrands  typed  on  the  Summary  TTY  by  the  operator. 

Each  IMP  sends  two  reports  tc  the  CNCC  corrputer  at  least 
once  every  52  seconds.  The  first  of  these,  the  status 
report,  provides  iLformation  about  the  operational  condition 
of  the  IMP  itself,  mcaens,  and  connected  hosts;  the  second, 
the  throughput  report,  provides  data  throughput  information 
in  terms  of  both  words  and  packets  for  all  modems  and  hosts. 
If  these  reports  suggest  a  change  in  status  of  any  network: 
component,  the  CNCC  will  output  a  message  on  the  Logger  TTY 
that  may  require  action  by  the  CNCC  rperatcr.  The 
statistical  information  is  accumulated  and  output  en  the 
Summary  TTY  either  automatically,  in  response  to  an 
interrupt  from  the  realtime  clock,  or  on  demand,  in  response 
to  a  command  from  the  Network  Controller. 

The  CNCC  program  accepts  commands  typed  by  the  operator 
on   the  Summary   TTY  and  performs  a  variety  of  functions  to 
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mcnitcr  and  conirol  the  neiworlc  ccnf  Igurat  Icn .  These 
functions  include  reloading  or  restarting  an  IMP,  testing  a 
host  cr  rricdem  interface,  cr  selecting  one  of  the  statistical 
surrmary  reports  for  display. 

E.   ROLE  OF  THE  NETVORjl  CONTROLLER 

The  COINS  Networlc  Controller  is  responsible  for  overall 
OFeratlcn  of  the  network.  It  it  irrportant  to  note  that, 
although  ve  often  refer  to  the  Network  Controller  as  "the 
operator",  bis  diities  are  considerably  broader  than  those  of 
a  ccmputer  operator  in  a  traditional  ADP  center  [Ref.  5]. 
The  Network  Controller's  role  includes  the  coordination  and 
monitoring  of  network  perf crrriance,  production  cf  network 
status  reports,  diagnosis  of  failures  of  network  components, 
and  direction  of  recovery  procedures.  Given  the  distributed 
nature  of  the  COINS  II  network,  the  Controller  has  first- 
crder  responsibility  for  network  operations.  The  najcr 
duties  of  the  Network  Controller  are  sumrarized  in  this 
section  [Hef.  2:  pp.  1-10  -  I-ll] . 

The  NetworK:  Controller  is  responsible,  first  of  all,  for 
operating  the  CNCC  corrplei.  This  includes  the  loading, 
starting,  and  norrral  operation  of  both  the  CNCC  and  the 
Master  IMP  programs.  Although  in  this  thesis  v-e  are 
prirrarily  concerned  with  the  CNCC  H-316  computer,  the  CMCC 
Network  Controller  is  responsible  for  a  much  larger  hardware 
suite.   Other  computers  in   the   CNCC   complex   include   the 
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PDP-11/70  Terniinai  Access  Syster  (TAS)  that  interfaces  32 
user  terrrinais  to  the  network;  the  Network  Service  Hcst 
(NSE),  another  PEP-11/70  systen;  used  for  research  end 
deveicpment  and  network  software  support?  and  several  other 
special-purpose  computer  systerrs  ['Ret.  6:  p.  2-4].  It  is 
planned  that  ultimately  the  NetworU:  Controller  could  monitor 
all  these  systems  from  a  single  integrated  operator  console. 

The  network  monitoring  activity  consists  mainly  of 
observing  the  CNCC  Logger  reports  and  properly  interpreting 
error  and  failure  indications.  Duties  include  coordinating 
network  status  with  the  COINS  PMO,  scheduling  of  special 
network  tests,  gathering  performance  and  throughput 
statistics,  verifying  the  programs  at  the  network  IMPs,  and 
the  coordinating  any  needed  maintenance  support.  The 
Network  Controller  is  also  responsible  for  monitoring  the 
CNCC  hourly  summary  reports,  requesting  additional  reports 
if  necessary,  and  off-loading  report  files  end  network 
statistics  to  the  TIPSl  system  at  NSA  for  further  processing 
and  analysis. 

The  most  important  duties  of  the  Network  Controller  are 
tnose  that  affect  the  day-tc-day  operation  of  the  network. 
These  include  diagnosing  network  or  user  problems, 
conducting  network  tests  to  measure  perfcrmarce,  and 
releasing  new  software  to  the  network  ir^Ps.  The  Network: 
Controller's  fundamental  responsibility  is  to  keep  all 
network  components  operating  at  a  level  that   assures   users 
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of  reliable  and  tirrely  service.  Additionally,  he  serves  as 
the  focal  point  for  questions,  problems,  and  corrplaints 
about  all  aspects  of  networi:  operation. 

C.   CNCC  INPUTS  AND  OUTPUTS 

1.   Surrmary  Teletype  Output 

The  [r.essages  printed  on  the  Sumrrary  TTY  contain 
netwcrlc  information  that  has  teen  compiled  by  the  CNCC 
cofrputer  from  IMP  status  and  trouble  reports.  Summary 
reports  fall  into  three  general  categories:  those  that 
provide  information  on  the  current  status  of  network 
componentsJ  those  that  provide  accumulated  summaries  of 
status  information;  and  those  thct  provide  accumulated 
summaries  of  host  and  line  throughput[Pef  2:  Appendix  B] . 
The  Networic  Controller  can  select  any  of  these  reports  by 
entering  commands  at  the  Summary  TTY.  In  addition, 
accumulated  summaries  of  throughput  and  status  information 
are  output  automatically  every  four  or  eight  hours.  The 
appropriate  operator  commands  are  described  below. 

There  are  two  current  status  reports:  OUICKPRINT  end 
HOST  STATUS.  The  QUICKPRINT,  a  sample  of  which  is  shown  in 
figure  4,  uses  one-character  codes  to  describe  the  current 
status  cf  all  IMPs  and  lines  in  the  network.  This  report 
also  displays  any  unusual  situations  {e.g.,  sense  svvitches 
ON,  CVERRIEE  ENABLED,  etc.)  The  following  status  code 
definitions  are  used  in  the  OUICKPRINT  report: 
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2532  AUGUST  5  1981   QUICK  SUMMARY 


IMP 


12345e78y0  i:£34 
+<.??. . .??  ???. 
LINE 


IMP  1  SS  4  ON 

MSa  GEN  ON 


Figure   4.      Sarrple   CUICKPRINT   Report 
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?  -  status  unkncwn 

up 
^     -     down 
+  -  plus  side  of  line  down 

rrinus  side  of  line  down 
>  -  plus  side  of  line  looped 
<  -  minus  side  of  line  Iccped 
Z  -   both  sides  of  line  looped 

The  HOST  STATUS  rejort  gives  the  current  status  of  all  hosts 
in  the  netwcrK  or  of  only  those  hosts  connected  to  a 
specific  Il^P.  A  sarrple  EOST  STATUS  report  is  shown  in 
iigure  5. 

The  CNCC  accumulates  status  information  on  ell  I(^Ps 
and  lines  on  a  daily  basis.  This  information  is  displayed 
in  the  STATUS  report.  Status  is  reported  in  ternrs  of  15 
minute  segments  such  that  an  entry  is  printed  for  a  time 
period  only  if  the  status  of  one  of  the  corrponents  changed 
during  that  interval.  The  STATUS  report  errplc/s  the  same 
set  of  cedes  used  in  the  QUICKPRINT  with  the  addition  that, 
if  the  status  of  any  IMP  or  line  has  charged  auring  the 
interval,  its  status  will  be  shown  as  "x".  A  sample  of  the 
STATUS  report  is  shown  in  Figure  6.  The  IMP  and  line  STATUS 
reports  are  automatically  summarized  and  output  three  times 
a  day,  at  0600,  1600,  and  2400. 

The  CNCC  compiles  throughput  statistics  en  the 
amount   of   traffic   transferred   between  hosts  end  over  the 
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Figure  6.   Sample  STATUS  Report 
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lines  of  ihe  network.  This  inforriiation  can  te  displayed  in 
eiiher  ol"  two  reports:  the  hourly  THRUPUT  summary  report  and 
the  eight-hour  DAYSUM  report.  The  formats  of  these  reports 
are  identicalJ  the  statistics,  however,  may  differ  somewhat 
depending  on  the  time  of  the  request. 

In  the  THRUPUT  report,  shown  in  Figure  7, 
information  is  arrangea  by  IMP  and  within  each  IMP  by 
physical  host  address  with  the  virtual  host  address  (VHA)  in 
parentheses.  Host  throughput  is  reported  in  terms  of  the 
number  of  messages  and  packets  sent  and  received  for  both 
inter-site  and  intra-site  traffic.  The  following  symbology 
is  used  to  denote  the  information  unit  and  path  direction  in 
the  THRUPUT  report: 

M->N  Messages  sent  to  hosts  at  other  network  sites. 

M<-N  Messages  received  from  hosts  at  other  sites. 

P->N  Packets  sent  to  hosts  at  ether  sites. 

P<-N  Packets  received  from  hosts  at  other  sites. 

M->S  Messages  sent  to  hosts  at  the  same  site. 

M<-S  Messages  received  from  hosts  at  the  same  site. 

P->S  Packets  sent  to  hosts  at  the  same  site. 

P<-S  Packets  received  from  hosts  at  the  same  site. 

Throughput  figures  less  than  32,767  are  ezact;  those 
between  32,766  anc  2,^^97,151  are  accurate  to  within  Z%',  and 
those  greater  than  2,097,151  are  shown  as  -+++++^-r. 
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2.   Log,ger  Teletype  Output 
a.   General 

The  description  of  the  Summary  teletype  outputs 
was  relatively  straight  forward,  since  the  outputs  were 
well-defined  and  fairly  predictable.  Such  is  not  the  case 
when  we  consider  the  outputs  that  appear  on  the  logger 
teletype.  We  recall  that  the  Logger  TTY  is  used  for  alert 
type  messages,  many  of  which  require  some  action  hy  the 
Network  Controller.  Appendix  B  of  Reference  Z  contains  a 
list  of  93  possible  output  messages  that  may  "be  sent  to  the 
Logger  TTY.  Many  cf  them  are  merely  informational  in  nature 
and  are  useful  primarily  for  later  diagnosis  and  tracing  of 
events.  It  is,  therefore,  neither  necessary  r.or  desirable 
for  our  purposes  to  describe  them  all.  Instead,  we  will 
present  the  general  form  of  the  Logger  messages  and  describe 
those  that  pertain  to  the  overall  performance  of  the 
network.  The  messages  with  which  we  will  be  concerned  are 
mainly  these  that  will  activate  the  COINS  alarm  bcx  to 
audibly  alert  the  Network  Controller.  These  messages  are 
the  ones  that  would  be  candidates  tc  be  sent  to  a  voice 
output  device.  A  fuller  discussion  of  Logger  messages  is 
found  in  Reference  3. 

All  Logger  messages  have  the  following  general 
form: 

<time>  <repcrting  net  component>:  <event  descr> 


34 


where  <reporting  net  coirponent>  is  some  IMP  or  line  and 
<;eveni  descr>  is  a  brief  message  describing  the  specific 
event.   Some  exairpies  are: 

Z?45    II^.P   1:   VIRT-HOST  12    DOWN 
134y   LINE   8:   ERRORS  MINUS  5/6 
1250    IMP   5:   TRAP   (74:,  401,   1) 

In  the  remainder  of  this  section,  we  will  describe  some  of 
the  more  important  Logger  TTY  messages. 
1).   BAE  HOST  DATA  CHECKSUM 

Each  IMP  has  internal  tables  on  which  it  bases 
message  routing  and  delivery  decisions.  Should  one  of  these 
tables  become  disturbed,  for  example  because  of  a  program 
crash,  this  message  will  appear  on  the  Logger  at  one  minute 
intervals  until  the  table  is  repaired. 

c.  HOST  N  DOWN 

The  IMP  is  reporting  thai  physical  host  N  has 
dropped  its  ready  line.  A  variation  of  this  message  is 
' VIRT-HOST  N  down"  which  provides  the  same  information  for  a 
host  that  is  assigned  a  virtual  host  number.  Because  local 
host  operation  is  not  a  CNCC  responsibility,  this  message  is 
mainly  to  provide  information  that  might  be  used  to  answer 
user  queries. 

d.  IMP  N  DOWN 

The  neighbors  of  IMP  N  have  reported  that  the 
lines   to   that  IMP  are  down.   The  CNCC  has  decided  that  the 
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IMP  is  not  available  for  network  service  although  it  may 
still  be  actually  running  ana  able  to  corrrr.unicate  with  its 
local  hosts . 

e.  LIN2  X  DOWN 

The  IMPS  at  either  end  of  line  X  have  declared 
the  line  dead.  The  CNCC  makes  the  decision  to  report  the 
line  dead. 

f.  LINE  X  DOWN  PLUS  (or  MINUS) 

The  end  of  a  line  which  is  connected  to  the 
higher  nurrbered  IMP  is  defined  to  be  the  "plus"  side  of  the 
line;  that  connected  to  the  lower  numbered  IMP  is  the 
"minus'  side.  This  logger  message  is  similar  to  the 
previous  one  except  that  the  IMP  at  only  one  end  of  the  line 
is  reporting  a  problem. 

g.  TRAP   (T,A,X) 

The  reporting  IMP  has  detected  an  internal 
anomaly.  the  T,  A,  and  X  values  provide  fi:rther  information 
about  the  trap.  Usually  these  messages  are  of  interest  to 
network  software  personnel  cnlyj  some  of  them,  however, 
require  operator  action  to  clear  up  the  error  condition, 
h.   CRASH   (T,A,X) 

This  message  indicates  that  the  reporting  IMP 
has  detected  a  serious  program  malf^jnction  that  caused  the 
program  to  crash.  It  has  reloaded  itself  and  the  program  is 
now  up  and  running.  T,  A,  and  X  contain  register  values 
useful  to  software  personnel  diagnosing  the  failure. 
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i.   VIRT-HCST-TBL  X 

This  message  indicates  that  the  serial  rumber  of 
the  reporting  ir^P's  virtual  host  adaress  ( VEA )  table  differs 
from  the  master  in  the  CNCC  computer.   Appropriate   operator 
action  is  required  to  [r,aice  the  serial  numbers  consistent. 
3.   Network  Controller  Cor.irands 

a.   General 

As  was  the  case  with  the  Logger  TTY  ressages 
there  are  a  large  number  of  CNCC  operator  commands  that  do 
not  concern  us.  We  will  be  concerned  primarily  with  those 
that  are  used  frequently  in  network  monitoring  and 
troubleshooting.  These  are  also  the  commands  that  are  good 
candidates  for  voice  input.  Commands  to  the  CNCC  are 
preceded  by  the  commana  sentinel  character  "?"  and  consist 
of  a  1-3  character  command  mnemonic  followed,  optionally,  by 
additional  command-dependent  parameters  such  as  filenamps, 
If^P  numbers  etc.  In  the  discussions  that  follow,  operator 
entries  are  in  upper  case  and  underlined*  prompts  and 
responses  by  the  CNCC  are  ail  in  lower  case.  Expressions  in 
angle  Drackets,  e.g.  <fILENArE>,  are  used  to  represent  ASCII 
strings.  The  "$*  character  is  used  to  denote  the  ASCII 
escape  character  (cctal  vi3 )  .   Some  examples  are: 


?REPort  Daysum: 

TBroadcast  file:  <FILENAME>$  imp;  <#>$ 


CNCC  commands  can  be  grouped  into  three  broad 
categories:  commands  used  to  produce  summar/  reports? 
commends  used  to  manipulate  local  CNCC  files?  and  commands 
used  for  remote  transmission  of  files  between  the  CNCC  and 
other  networic  components.  For  a  complete  list  of  CNCC 
commands,  see  Appendix  E  of  Reference  3. 

b.  Summary  Report  Commands 

To  request  a  specific  summary  report,  the 
Controller  types  ?REP  and  the  first  letter  of  the  report 
type  (e.g.  D  for  DAYSUM  report).  The  command  is  terminated 
by  typing  a  colon.  The  following  are  the  commands  fcr  the 
various  summary  reports: 

?REPort  Quiclfp: 
?RZPort  Host  status: 
7REPort  Host  status  imp:<#>? 
?REPort  Status: 
?REPort  Thrptsum: 
7REPort  Daysum: 

c.  Local    i'lle    Coirmands 

Local  file  commands  allow  the  operator  to 
perform  routine  operations  on  local  CNCC  files.  The 
following  examples  illustrate  the  types  of  commands 
available.  lor  a  mere  complete  description  see  Section  III 
of  Reference  3. 
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?Prlni  Directory 

?Frlnt  Total   (disic  space  available) 

?R2Naine  (old)  <FILENAME>$  (new)  <FILENAME>^ 
d.   Remote  File  Transfer  Commands 

The  corrmands  used  to  transfer  files  between  the 
CNCC  and  ether  components  in  the  COINS  network  are  probably 
the  most  important  of  ail  the  operator  commands.  They 
provide  the  Netvcrk  Controller  with  a  means  of  reloading 
remote  IMPs  and  correcting  other  network  problems.  One  of 
the  most  frequently  used  commands  is  the  BROADCAST  command 
which  has  the  following  general  form: 

?Brcadca5t  file:  <EILEi\AMS$  imp:  <#?>$ 

where  <FILENAr^E>  determines  the  specific  action  and  <#>  is 
the  IMP  number  to  which  the  file  will  be  sent.  Numerous 
examples  of  the  use  of  this  command  can  be  found  in 
Reference  3. 

To  correct  certain  types  of  checksum  errors,  the 
Controller  uses  the  RELOAD  command  which  has  the  following 
general  form: 

?REIoad  file:  <irPSYS  ####BIN##>$ 
rrodem:  <#>$  imp:  <#>$ 

where  <I(*^FSIS  ####  BIN  ##>  is  the  narre  of  the  latest  version 
of   the   ir^P   program  ard  <>fr>  refers  to  the  modem  rumber  and 
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the  irP  nurrber  of  a  neighbor  IMP  to  the  one  reporting  the 
checicsum  errors. 

On  occasion,  the  operator  wants  to  transfer  a 
file  frorr  the  CNCC  disk  to  another  COINS  host.  Cften,  these 
are  statistical  files  sent  to  another  host  for  follow-on 
processing.  This  function  can  be  acconplished  by  the  S3ND 
corrmand  which  has  the  following  form: 

?SEnd  local-file  <CNCCFILE>^ 

to  host  <#>$  remote  file  narTie<REMf ILE>$ 

where  <CNCC?ILE>  is  the  aarre  of  the  CNCC  file  to  be 
transferred  end  <HSMFILE>  is  the  name  that  the  file  will 
have  in  the  file  system  of  the  remote  host. 

C.   LIMITATIONS  OF  CURRENT  CNCC  CONFIGURATION 

As  currently  configured,  tne  CNCC  has  a  number  of 
shortccmings  that  make  it  more  difficult  for  the  Network 
Controller  to  perform  the  basic  functions  of  network 
monitoring  and  control.  Although  not  all  cf  these  protlems 
are  germane  to  the  current  inquiry,  it  is  worthwhile  to 
discuss  each  of  them  briefly  to  put  the  existing  CNCC  in 
perspective. 

The  most  obvious  limitation  is  the  relatively  primitive 
hardware  in  the  CNCC.  The  CNCC  computer  has  only  32K  bytes 
cf  primary  memory  and  cannot  be  expanded;  this  places  a 
severe   constraint   on  its  ability  to  manipulate  and  enalyze 


40 


network  status  inforitat ion.  Tbere  is  insufficient  disk 
storage  tc  save  all  the  raw  data  that  is  sent  to  the  CNCC. 
As  a  consequence,  data  rrust  be  surr.rrarized  before  it  is 
stored  with  a  resulting  less  of  information.  The  CNCC 
output  devices  are  quite  slow  and  it  is  possible  to  lose 
traffic  in  peak  situations.  It  is  worth  noting  that  a 
nurrber  of  COINS  hosts  have  corrpieted  rr,ajor  hardware  upgrades 
while  the  CNCC  hardware  still  represents  the  technology  of 
the  early  li?70s  [Ref .  2:    p.  3-3]  . 

There  are  similar  problems  with  the  CNCC  software,  both 
with  the  analytical  routines  and  with  the  procedures  that 
interface  directly  with  the  operator.  Many  of  the  output 
rressages  are  cryptic  and  require  considerable  experience  and 
guesswork  to  interpret  correctly.  The  input  corrtrand 
language  is  also  net  very  human-oriented.  Some  of  the 
corrective  procedures  are  currbersorre  and  prone  to  error. 
Jor  example,  the  procedure  for  reloading  an  IMP  can 
sorTetimes  as  rr,any  as  eight  fairly  corrplicated  steps  [Ref.  2: 
p.  3-€] .  Humanized,  self-contained  output  messages  and 
simple  macro  type  input  commands  would  go  a  long  way  to 
simplify  the  Jot  of  the  Network  Controller. 

One  of  the  most  serious  problems  facing  the  Network 
Controller  is  Just  the  number  of  individual  consoles  that 
must  be  monitored.  As  notec  aoove,  the  CNCC  operator  is 
responsible  for  the  operation  cf  several  computer  systems  in 
addition  to  monitoring  the  Logger  and  Summery   TTYs.    While 
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tbese  systems  are  all  in  the  saire  general  area,  it  is  not 
possible  tc  monitci  and  operate  ail  the  systerrs  effectively 
without  a  considerable  arrount  of  physical  moverrent.  One 
study  shewed  that,  in  the  course  of  a  typical  week,  the  CNCC 
operator  rrade  S03  separate  "trips"  "between  various  positions 
and  covered  a  distance  of  over  five  miles.  More  significant 
than  total  distance  is  the  feet  that  the  frequent 
interruptions  make  it  hard  for  the  Controller  tc  maintain 
effective  continuity  over  all  the  positions.  He  will  too 
often  be  at  the  wrong  console  at  the  wrong  time  and  thus 
miss  some  Important  messages. 

These  shortcomings  cannot  be  eliminated  by  a  piecemeal 
approach.  Ultimately,  the  CNCC  will  heve  to  be  replaced  by 
a  modern  computer  system  that  enhances  and  simplifies  the 
job  of  network  management.  Flans  for  such  an  upgrade  have 
been  developed  by  the  COINS  PMC.  A  turnkey  replacement 
system  is,  however,  several  years  away.  Advances  ir  Voice 
Input/Output  (VIC)  technology  over  the  last  several  years 
provide  the  potential  to  make  some  important  interim 
improvements  at  comparatively  moderate  cost.  In  the 
remainder  cf  this  paper,  we  will  take  a  closer  lock  at  voice 
technology  and  examine  ways  that  it  might  be  adapted  to  the 
existing  system  to  increase  the  effectiveness  of  the  COINS 
Network  Controller. 
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17.   VOICE  INPUT/OUTPUT  TECHNOLOGY 

A.   GENERAL 

As  we  ncted  in  the  previous  section,  several  of  the 
problems  faced  by  the  CNCC  Netvort  Controller  could  be 
categorized  as  shortccmings  in  human  factors  engineering. 
One  way  of  improving  the  human  aspect  of  any  system  is  to 
simplify  the  procedures  used  to  communicate  the  intentions 
of  the  human  operator  to  the  system.  Another  is  to  provide 
a  better  way  of  notifying  the  operator  that  a  significant 
event  that  requires  his  attention  has  occurred.  What  we 
will  attempt  to  do  in  the  remainder  of  this  thesis  is 
explore  and  highlight  ways  of  achieving  these  two 
fundamental  Improvements  to  the  current  CNCC  system.  On  the 
input  side,  we  will  examine  the  uses  of  Automatic  Speech 
Recognition  (ASR)  equipment;  on  the  output  side,  we  will 
consider  the  use  of  voice  output  techniques,  such  as  speech 
synthesis.  Input  and  output  will  be  discussed  separately  in 
more  aetaii  in  3.  and  C.  below.  In  the  remainder  of  this 
section,  we  will  outline  the  overall  approach  of  the 
investigation. 

The  approach  tradit icnaiiy  used  to  evaluate  the 
potential  of  ASR  for  a  particular  application  has  been  to 
conduct  what  are  called  [Ref.  7:  p.  4]  "evaluation 
experiments".    Evaluation  experiments  are  the  most  rigorous 


type  cf  eiperirent  and  usually  involve  careful  control  of 
experimental  conditions,  a  number  of  replications,  and  a 
forrral  analysis  of  numerical  measurement  data.  References  8 
and  y  are  good  examples  of  the  use  of  evaluation  experiments 
to  determine  the  usefulness  of  speech  recognition  in  a 
particular  application  environrrent .  There  are  a  number  of 
advantages  to  this  approach,  the  most  obvious  being  that  the 
conclusions  are  bolstered  hy  hard  statistical  evidence.  The 
disadvantage  is  that  it  is  often  difficult  and  expensive  to 
develop  experimental  models  that  realistically  portray 
real-world  situations. 

For  a  number  of  reasons,  we  decided  not  to  use  a  formal 
evaluation  experiment  for  the  CNCC  study.  First  of  all,  the 
CNCC  is  a  complex  man-machine  system  that  is  extremely 
difficult  to  model  realistically  in  a  controlled  experiment. 
Events  in  the  network  are  not  deterministic  and  by 
introducing  the  controls  necessary  for  a  formal  experiment, 
we  run  the  risk  of  building  a  model  that  does  not  accurately 
portray  the  real  system.  Related  to  this  is  the  difficulty 
of  obtaining  people  with  adequate  background  to  serve  as 
experimental  subjects.  CNCC  operators  were  net  available 
and  even  subjects  with  extensive  computer  experience  would 
have  to  have  lengthy  specialized  training  to  participate  in 
such  an  experiment.  The  fact  that  ve  were  looking  both  at 
voice   input  and  voice  output  was  an  additional  complication 
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thai  cculd  necessitate  additional   replications   and   hence 
increase  the  cost  of  the  experiment. 

A  more  positive  reason  for  adopting  a  different  strategy 
was  that  a  formal  experiment  was  really  not  necessary. 
Automatic  Speech  Recognition  has  matured  to  the  extent  that 
we  can  feel  reasonably  confident  in  extrapolating  results 
from  earlier  experiments.  One  of  the  landmark  experiments 
in  ASR  involved  a  group  of  24  experimental  subjects  who  used 
voice  recognition  equipment  to  verbally  enter  commands  to 
the  ARPANET  [Ref.  6].  The  subjects  carried  out  a  predefined 
scenario  using  both  voice  input  and  typing  input.  The 
subjects  vere  also  required  to  perform  a  secondary  task 
during  any  free  time  that  ihey  had.  The  results  of  the 
experiment  LRei"'B:  p.  2]  shoved  that  with  only  three  hours 
cf  training  practice: 

—  voice  input  was  17.5%  faster  than  manual  typing? 

—  manual  typing  input  had  183.2%  more  entry  errors  J  and 

—  voice  input  allowed  subjects  to  complete  25%  more  of 
the  secondary  task  than  did  manual  typing. 

It  is  clear  that  there  are  a  number  of  similarities 
between  the  scenario  in  the  ARPANET  experiment  and  the 
operational  environment  in  the  CNCC.  The  CNCC  operators  are 
also  involved  in  entering  commands  tc  a  distributed  computer 
networlc  that  uses  ARPANET  technology;  the  operator  is,  of 
course,  always  performing  a  secondary  task  since  the  Network 
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Controller  is  continually  occupied  with  responding  to  output 
requests  on  a  nurrber  of  display  consoles.  We  believe,  then, 
that  the  general  conclusion  cf  the  experiment,  that  it  is 
feasible  to  use  current  corrmercially  available  voice 
recognition  equipment  to  run  many  operations  of  an  ARPANET 
type  network,  can  also  be  applied  to  the  CNCC. 

In  terms  of  voice  output  there  is  less  hard  experimental 
evidence  of  applicability.  There  are  some  examples, 
however,  where  voice  response  units  have  been  used  in  place 
of  traditional  alarm  devices;  it  seems  intuitively 
attractive,  furthermore,  that  voice  output  would  provide 
coDslderably  more  information  than  a  buzzer  or  bell. 

The  relatively  moderate  cost  of  current  voice  input  and 
output  equipment  is  also  a  factor  in  deciding  against  a 
full-scale  evaluation  experiment.  As  long  as  there  is 
reasonable  evidence  that  the  technology  will  be  useful, 
there  is  fairly  low  economic  rlsi£  in  trying  to  apply  it.  If 
the  basic  applicability  can  be  verified;  the  feasibility 
demonstrated;  and  one  or  more  possible  implementation 
alternatives  developed,  there  is  a  high  probability  of 
successful  installation  and  operation. 

Our  methodology,  therefore,  has  taken  two  different,  but 
related,  paths.  First,  we  have  researched  the  field  of  VIO 
technology  to  understand  the  capability  and  cost  of  the 
available  equipment  and  its  potential  applicability  in  the 
CNCC.   Second,  we  have   implemented   a   training   simulation 
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model  of  the  CNCC  that  is  useful  both  to  demonstrate  the  use 
of  VIO  in  the  CNCC  and  to  permit  experirrentation  with 
alternative  implerentaticn  approaches  without  interrupting 
the  production  system.  The  model  can  also  he  used  to 
familiarize  CNCC  operators  with  voice  technology  equipment 
before  actually  installing  it  on  line.  Based  on  these  two 
parallel  efforts,  we  then  aeveloped  some  strategies  for 
installing  VIO  in  the  current  CNCC  without  major 
modifications  to  an/  of  the  existing  hardware  or  software. 

B.   VOICE  INPUT 

1 .   Typical  Applications  of  Voice  Input 

Until  the  mid-iy70s,  automatic  speech  recognition 
(ASP)  was  used  primarily  to  develop  vocoders  for  narrow-bana 
speech  communications.  With  the  increasing  availability  of 
high  quality,  moderately  priced  systems  for  speech 
recognition,  however,  the  number  of  potential  and  actual 
applications  has  mushroomed.  Limited  vocabulary  voice  input 
systems  have  movea  out  of  the  laboratories  and  are  now 
operating  in  a  variety  of  applications  in  both  private  and 
public  sectors,  "^liamples  include  automated  sorting  systems 
for  the  distribution  of  parcels,  containers,  acd  baggage; 
voice  programming  for  machine  tools;  quality  control  and 
inspection;  air  traffic  control;  entry  of  cartograjhic  data; 
and  aids  for  the  handicapped  [Ref.  12:  pp.  182-186].  While 
this   large  number  of   potential   uses  precludes  detailed 
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discussion  of  them  all,  it  would  be  well  to  briefly  discuss 
a  few  of  therr  before  we  try  to  generalize  about  the 
characteristics  of  applications  where  ASR  is  liiiely  to  be 
successful. 

Voice  input  devices  have  fceen  used  in  material 
handling  applications  since  the  mid  1970s  and  have  resulted 
in  increased  operator  productivity  and  reduced  error  rates 
over  their  predecessors  that  required  operators  to  hand  key 
the  sorting  destination  codes.  A  typical  exarple,  is  the 
voice  control  package  routing  system  developed  at  S.S  Kresge 
in  19T4.  As  parcels  arrive  at  the  induction  station,  the 
operator  simply  states  the  destination  cede  for  each  package 
into  his  microphone  headset.  The  computer  recognizes  the 
spoken  destinatior  code  and  generates  the  appropriate  code 
as  if  it  had  come  from  a  keyboard.  This  "sorting  by  speech" 
increased  productivity  and  eliminated  a  serious  problem  of 
"bunching"  of  different  size  packages  at  the  induction 
station  [Hef .  I0:  p.  165] . 

A  longstanding  bottleneck  in  computer-based 
manufacturing  control  systems  has  been  the  delay  in  getting 
machine  tool  programming  requests  translated  into  working 
software.  Traditionally,  factory  personnel  would  identify 
necessary  moaif ications  in  the  form  of  drawings?  these  would 
be  converted  to  specif ications 1  translated  into  a  computer 
program  manually?  converted  to  tape;  and,  finally,  installed 
in   the  machine   control  unit.   A  form  of  voice  programming 
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has  been  developed  that  allows  factory  supervisors  to 
directly  control  the  computer-based  processes.  Voice 
programming  for  numerical  control  (YNC)  allows  the  factory 
personnel  to  speak  commands  in  stylized  English  that  are 
automatically  translated  into  a  computer-coirpati  b  le  format. 
No  special  programming  sifills  are  required  ard  the 
"programmers"  hands  are  free  to  handle  blueprints  or  perform 
supporting  calculations.  VNC  has  transformed  what  was  a 
seven  step  process  fraught  with  the  danger  of  error  that 
creeps  in  whenever  complicated  human  communications  are 
required  into  a  workable  four  step  process  under  the  direct 
control  of  the  people  using  the  results  [Ref.  10:  pp.  165- 
186]  . 

ASR  has  not  been  used  as  extensively  in  the  public' 
sector  although  experimental  results  and  liirited  operational 
experience  seen  quite  promising.  As  noted  above,  Foock 
[Ref.  8]  has  demonstrated  that  using  voice  input  to  exercise 
a  typical  scenario  on  the  ARPANET  was  significantly  faster 
and  more  accurate  than  manually  entering  the  corrmands.  It 
has  also  been  used  operationally  at  CINCPACFLT  to  access  a 
large  intelligence  data  base  and  has  been  found  to  have 
considerable  potential  for  use  in  the  production  of  imagery 
interpretation  reports  [Ref.  9:  p. 95].  A  significant  amount 
of  research  has  been  performed  for  the  Defense  flapping 
Agency  (DMA)  on  ways  to  use  ASR  in  such  applications  es  the 
processing   of  Digital   Landmass   System   (DIMS)   data, 
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preparation  of  Flight  Inforrration  Publications  data,  and 
ocean-depth  rreasurements  for  digitized  cartographic 
applications.  These  cperaiicns  all  take  place  in  an  an 
environment  where  both  hands  and  eyes  are  continuously  busy 
and  frequently  involve  the  use  of  stereo  optics  or  other 
special  equipment.  Voice  has  teen  shown  experimentally  to 
be  faster,  easier,  and  less  fatiguing  to  the  operator  than 
more  traditional  methods  of  data  entry  [Ref.  9:  p.  37]. 

Lest  this  discussion  appear  too  one-sided,  there  are 
rrany  applications  for  which  voice  output  is  either  not 
desirable  or  not  cost-effective.  It  has  teen  shewn  to  be  c.f 
lirrited  utility  for  the  preparation  of  prcforma  messages 
and,  to  be  no  faster  than  typing  for  entering  commands  tc 
the  Warfare  Environmental  Sirrulator  (WES),  e  wargame  used  on 
the  Advanced  Command  and  Control  Architectural  Testbed 
(ACCAT).  Because  of  limitations  of  today's  technology, 
applications  that  require  speaker  independence,  vocabularies 
greater  than  about  220  words,  or  recognition  of  continuous 
speech  are  not  practical.  From  the  arcuat  of  experience  we 
have  had  to  date,  however,  it  is  possible  to  identify 
certain  characteristics  that  make  an  application  a  good 
candidate  for  voice  input.  We  will  discuss  these 
characteristics  in  the  next  section. 

2.   Characteristics  of  Candidate  Applications 

In  view  of  the  growth  in  operational  use  of  voice 
input   it   should   be  possible   tc   identify  a  set  of  task 
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/ 
situation  characteristics  where  the  use  cf  speech 
recognition  is  liicely  to  be  beneficial.  Reddy  [Ref.  11:  p. 
60]  presents  such  a  list  that  he  adapted  from  an  earlier 
study.  Using  this  list  as  a  starting  point,  we  can  define  a 
profile  of  characteristics  that  make  a  particular 
application  a  good  candidate  for  ASR.  It  is  unlikely  that 
rrany  operational  situations  will  exhibit  all  of  these 
features,  but  the  existence  of  even  two  or  three  provides  a 
strong  suggestion  that  The  use  of  speech  input  should  be 
exarined . 

The  single  characteristic  that  almost  all  of  the 
successful  applications  have  in  common  is  that  they  all 
involve  situations  where  the  operator's  hands  and  eyes  are 
already  busy  with  other  functions.  In  many  operations  a 
good  deal  of  productivity  is  lost  when  the  operator  has  to 
interrupt  his  ether  activities  to  input  data  via  a  keyboard. 
Voice  input  provides  an  independent,  high-bandwidth 
ccrrmunicat  ion  channel  that  is  tailcr-made  for  hands-busy 
operations . 

Related  to  the  first  consideration  is  the  condition 
where  the  operators  must  frequently  move  away  from  the  basic 
Input  station  to  attend  to  other  duties.  Wireless 
transmitters  the  size  of  a  cigarette  pack  can  provide  a 
considerable  range  of  operation  permitting  the  operator  to 
communicate  with  an  ASR  system  without  returning  to  the 
input  console.   It  is  interesting  to  observe  that  the  use  of 
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voice  input  in  such  situations  might  suggest,  or  even 
necessitate,  the  use  of  sorre  type  of  audible  feedbecic  system 
(i,e.  speech  output)  since  the  operator  will  not  always  be 
in  the  vicinity  of  the  speech  input  device  or  its  associated 
teletype  or  CRT. 

Some  applications  involve  what  Fight  be  called 
"virtual  mobility  requirements,  in  addition  to  or  instead 
of,  the  "physical"  mobility  just  described.  For  exanrple,  it 
may  be  necessary  to  access  a  number  of  different  computer 
systems  through  a  common  terminal  or  console.  The  ARPANET 
experiment  provides  a  ^ood  example.  In  the  ARPANET,  the 
host  computers  use  different  command  languages,  query 
languages,  and  file  management  systems.  This  heterogeneity 
can  sometimes  te  confusing  to  even  experienced  users.  For 
example,  the  UNIX  command  to  delete  a  file  is  'rm'j  while 
the  comparable  DECsystem-2e  command  is  'DEL'.  To  display  a 
directory  of  files  on  UNIX,  the  user  types  'is  -1';  on  the 
DEC-20,  be  types  'DIR'.  Veil-designed  voice  input  systems 
can  alleviate  these  problems,  to  at  least  some  extent,  by 
making  these  different  corrnand  languages  transparent  to  the 
operator.  For  example,  cne  widely-used  system  allows  for 
the  definition  of  vocabulary  sets  that  can  provide  a  mapping 
between  standard  input  phrases  and  different  output 
character  strings  depending  on  the  application  context  or 
the  particular  host  computer  being  accessed.  In  our  second 
example  aoove,  the  operator  might  always   utter   the   phrase 
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"display  directory"  and  the  voice  input  system,  in 
cooperation  with  the  host  computer,  would  perform  the 
transformation  to  the  appropriate  character  string.  Voice 
input  can  also  reduce  complex  connection  protocols  to  one  or 
two  natural  phrases  that  malce  it  easy  to  establish  logical 
connections . 

Voice  input  systems  are  ideal  for  use  by  untrained 
users.  No  physical  skills,  such  as  typing  or  other  keyboard 
manipulation,  are  required.  The  naturalness  and  hum^anness 
of  the  speech  input  interface  make  it  applicable  for  usFrs 
at  all  general  skill  levels:  from  clerical  personnel,  to 
computer  operators,  to  tcp-ievel  managers. 

Operations  where  speed  and  accuracy  of  communication 
are  essential  are  alsc  excellent  candidates  for  voice  input. 
In  the  ARPAMT  experiment,  significant  improvements  (see 
above)  in  the  speed  and  accuracy  of  data  entry  were  attained 
even  tnough  the  test  subjects  had  no  previous  experience 
with  voice  input.  Some  studies  have  found  that  peak 
efficiency  is  net  attained  until  the  operators  have  had  3-4 
months  of  experience.  This  suggests  that  even  greater 
productivity  gains  can  be  realized. 

Because  of  technological  limitations,  which  we  will 
pursue  in  detail  in  the  next  section,  candidate  applications 
sho\;ld  have  a  relatively  limited  input  vocabulary. 
Contemporary  voice  recognition  systems  will  support 
vocabularies   of   from   about   ^0   to   over   250    discrete 
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utterances  or  phrases.  Applications  with  a  well-defined  but 
lirrited  command  set  are  the  most  likely  candidates.  Most  of 
the  vocatuiary  should  be  capable  of  being  "canned";  a 
language  that  contained  many  fields  with  arbitrarily  varying 
input  would,  therefore,  not  be  very  suitable.  For  a  related 
technclcgical  reason,  applications  with  an  input  language 
rade  up  of  discrete  commands  and  fields  is  much  more 
adaptable  to  voice  input  than  one  where  input  is  in  the  form 
of  unstructured  character  strings.  For  example,  current 
technology  would  readily  support  an  information  storage  and 
retrieval  system  Lsing  a  formatted  query  language  but  would 
be  inappropriate  for  a  word-processing  application. 

Having  defined  this  profile,  it  will  be  instructive 
to  compare  it  against  the  CNCC  operation  to  see  how  well  the 
CNCC  snapes  up  as  a  voice  input  candidate.  Figure  8  lists 
the  six  characteristics  and  a  subjective  assessment  of  how 
well  each  applies  to  the  CNCC.  We  see  that,  with  two 
exceptions,  all  the  features  are  present  in  the  Network 
Control  Center.  Tae  Network  Controller  is  often  busy  doing 
something  else  when  he  is  called  upon  to  input  commands  to 
the  system;  the  neea  to  control  a  number  of  systems  clearly 
requires  physical  mobility;  the  respors i bility  for 
maintaining  an  operating  CCINS  network  requires  that 
accurate  information  be  entered  quickly;  and  the  CNCC 
corrrana  language  is  snail  ana  reasonably  well  structured. 
The   CNCC   personnel  are  adept  at  entering  commands  and  data 
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1.  Hands    ti^sy,    eyes    cusy 

2.  Physical   rr.obilixy 
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Yes 
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Figure  5.  The  CNCC  as  a  Candidate  for  Voice  Input 
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into  corputer  systerrs  so  the  benefits  to  untrained  users  are 
not  really  relevant. 

The  only  uncertain  area  is  that  which  we  have 
called  "virtual"  robility.  There  is  no  question  that  such  a 
requirement  exists  in  the  CNCC.  Given  the  nun-ber  of  systems 
for  which  the  Network  Controller  is  responsible  even  a 
lirrited  arcunt,  of  ccnnectlcn-protccol  simplification  and 
corrirand  language  transparency  would  be  quite  beneficial. 
The  difficulty  is  that  voice  input  can  only  help  if  the 
systems  in  question  are  already  connected  electrically  and 
they  have  an  agreed-upon  protocol  for  connection,  even  a 
basic  timesharing  protocol  such  as  ARPA's  TELNET.  It  does 
not  appear  that  such  electrical  connections  and  protocols 
exist  tcday,  e.^.  there  appears  to  be  no  method  of  accessing 
the  other  Tcchines  in  the  CNCC  complex  directly  from  the 
Summary  TTY.  Nonetheless,  in  view  of  the  overall  assessment 
shown  in  Yigure  6,  the  expectation  is  that  voice  input  can 
te  Of  considerable  benefit  to  CNCC  operations. 
3 .   OverviEw  of  Voice  Input  Technology 

Automatic  Speech  Recognition  is  a  subset  of  a 
trcader  intellectual  domain  known  as  Speech  Understanding. 
Speech  Understanding  systems  (SUSs)  bave  the  objective  of 
properly  interpreting  the  intent  cf  a  speaker  even  when  the 
speech  is  not  grammatically  correct  or  well-formed.  SUSs 
m.ust,  for  example,  take  into  account  the  tendencies  of 
speakers  to  talk  in  incomplete   context-sensitive   sentences 


end  :o  spriDicle  utteraEces  with  occasional  non-speech 
eienenis  such  as  "uhs",  '"Ya  knows",  etc.  It  is  irrportant  to 
note  that  SU£  are  not  so  much  interested  in  correct 
recognition  of  every  word  hut  rather  focus  on  the  rreaning  of 
entire  conversational  segments. 

Even  when  the  dorrain  is  relatively  restricted, 
perntting  the  use  of  task-specific  inf oriration,  the  job  of 
a  speech  understanding  system  is  truly  formidable  and 
efforts  to  Qdte  have  been  mostly  of  academic  interest.  In 
ILS  speaking  process,  a  speaker  transforms  concepts  into 
speech  through  processes  that  introduce  variability  and 
ncise.  In  an  attempt  to  understand  the  concepts,  the  system 
must  deal  with  phonemic,  lexical,  syntactic,  and  semantic 
levels  of  meaning  all  of  which  are  susceptible  to  the 
introduction  of  additional  noise  or  error.  In  the  words  of 
the  designers  cf  one  cf  the  prototype  SUS, 

Tc  comprehend  an  utterance  in  the  context  of  such 
errors,  a  speech  understandiLg  systerri  rrust  formulate  and 
evaluate  numerous  candidate  interpretations  cf  speech 
fragments.  Understanding  a  message  requires  us  to 
isolate  and  recognize  its  individual  words  and  parse 
their  syntactic  and  ccnceptual  relationships  [Ref .  12; 
p.  216]  . 

The  goals  cf  Speecn  Recognition,   in   contrast,   are 

mucn   less   anoiticus.    Instead   of  dealing  with  abstract 

concepts  like  meaning  and  understanding,  speech   recognition 

systems   attempt   to   solve   the  more  practical  problems  of 
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analyzing   the   acoustic   waveform   and    applying   pattern 
recognition  techniques  to  differentiate  between  utterances. 

ASR  systems  can  be  considered  as  belonging  to  one  of 
two  categories:  continuous  (connected)  speech  systerrs  or 
isolated  (discrete}  speech  systems.  (Seme  authors  draw  a 
distinction  cetkeen  continuous  and  connected  speech, 
regarding  the  latter  as  a  somewhat  simpler  problem.  In  this 
thesis  the  terms  are  used  interchangably . )  While  the 
distinctions  between  the  categories  are  often  blurred, 
discrete  systems  are  those  that  require  a  short  pause  (on 
the  order  of  100  to  200  ms }  between  utterances;  Connected 
systems,  on  the  other  hand,  can  recognize  words  without 
explicit  icncwiedge  of  their  endpcints.  Continuous  speech 
recognition  is  considerably  more  difficult  than  recognition 
cf  discrete  utterances,  first  of  all,  such  systems  must 
decompose  the  acoustic  waveform  into  phonemes  and  words  at  a 
real  time  rate.  This  naturally  requires  a  great  deal  of 
computational  power.  Secondly,  the  acoustic  variation  of 
ViOrds  spoken  in  connected  speech  is  different  than  when  the 
words  are  spoicen  discretely.  This  is  caused  by  the 
coart iculat ion  of  neighboring  sounds,  i.e.  the  positions  of 
the  tongue,  Jaw,  and  lips  in  a  speech  sound  are  affected  by 
the  previous  ani  future  positions.  Continuous  recognizers 
nust,  therefore,  be  very  sensitive  to  conversational  context 
[Ref.  13:  p.  27].  There  are  some  connected-speech 
recognizers   on   the   market   toaay   but   they  are  expensive 
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(^5e  ,0e?-^iee,  Z0£'}  and  their  capabilities  have  not  really 
been  evaluated.  Jor  the  rerrainder  of  this  thesis,  then,  we 
will  confine  our  discussions  to  discrete  recognition  systerrs 
which  are  cop-.mercially  available  in  price  ranges  frorr  as  low 
as  ^500  upwards  to  about  ^5,000. 

There  are  two  other  limitations  with  most  of  the 
conterrporary  systems.  The  first  deals  with  litritations  on 
vocabulary  sizeJ  the  seccnd  concerns  speaker-independence. 
Coirrrercially  available  systerrs  support  vocatularies  of  about 
40--2tc  discrete  utterances  or  "words".  (In  speech 
recognition  parlance  the  terms  "word"  and  "utterance"  are 
used  interchangeably,  even  though  the  term  "phrase"  might  be 
rrore  appropriate  since  utterances  ere  often  composed  of  more 
than  one  word.  In  addition  rost  systems  are  speaker- 
aependent,  i.e.  they  require  a  user  tc  first  train  the 
system  with  nis  voice  patterns  for  each  of  the  utterances  in 
the  vocabulary  before  using  the  system.  (An  exception  is 
the  type  of  recognizer  that  supports  only  a  very  specialized 
vocabulary,  e.g.  the  10  digits}.  For  most  applications, 
neither  restriction  has  rruch  practical  effect.  Very  few 
computer-related  applications  require  more  than  200 
utterances  and  training  is  usually  accomplished  quickly  and 
easily . 

Figure  9  shows  a  block  diagram  of  a  typical  discrete 
word  recognition  systeir.  While  the  diagram  and  the 
discussion  to  follow  describe  a  particular   implementation 
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Figure  9.   Biccic  Diagram  ci*  Typical  Speech  Recognition  System 

(i'rorr  Reference  10) 
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aescrioed  by  Thorras  B.  rartin  of  Threshold  Technology,  Inc. 
[Re*'.  10:  pp.  176-176],  the  general  approach  applies  to  most 
of  the  systerrs  a\ailable  today.  As  the  diagram  shows,  the 
syster  takes  a  spoken  utterance,  attempts  to  match  it  with 
one  of  its  pre-stored  voice  patterns,  and,  if  successful, 
outputs  a  pre-defined  string  of  characters  over  a  standard 
RS-232  interfece  to  e  host  coirputer.  In  our  example,  the 
spoken  phrase  "Clear  Crash  Imp  3"  generates  the  output 
character  string  "?BCLEAR  CRASE<esc>3<esc>"  which  is  the 
proper  operator  entry  at  the  Summary  TTY  in  response  to  a 
numoer  of  observed  network  problems  (e.g.  IMP  CRASH 
messages,  PACKAGE  =  n  messages,  etc.)  This  example 
illustrates  a  number  of  important  points  about  ASR .  First, 
the  spoken  utterance  is  considerably  more  natural  than  the 
typed  command  string.  Second  and  probably  more  important, 
the  voice  input  device  is  completely  transparent  to  the  host 
computer  (in  this  case  the  CNCC  machine).  As  far  as  the 
host  is  ccncerned,  it  is  getting  character  strings  in  the 
same  code  and  at  the  same  bit  rate  as  if  they  had  been  typed 
manually.  Thus  no  host  software  modifications  are  required 
in  the  host.  This  is  critical  in  light  of  the  complexity  of 
the  CNCC  program,  the  limited  primary  memory,  and  the 
consequent  difficulties  in  raking  software  changes. 

We  see  from  ligure  9  that  a  system  consists  of  four 
oasic  components:  a  microphone  transducer,  a  preprocessor,  a 
feature  extractor,  and  a  final   decision   level   classifier. 
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Early  speech  recognition  systems  were  weakest  in  terms  of 
feature  extraction,  often  deleting  the  function  completely 
or  using  a  rudimentary  form  of  template  matching  which 
proved  inadequate  and  was  soon  rejected. 

The  micrcphone,  of  course,  is  the  interface  between 
the  user  ana  the  system  and  converts  the  spoken  phrase  into 
an  electrical  signal  thai  can  oe  analyzed  by  the  ether 
components.  The  preprocessor  performs  a  number  of  functions 
on  the  electrical  signal.  It  normalizes  the  signal  in  time 
so  that  it  can  be  later  compared  with  the  reference 
patterns.  Dynamic  programrring  is  one  technique  used  to 
achieve  this  time  adjustment  or  warping.  The  preprocessor 
also  performs  classical  tiire  or  frequency  domain  anal/sis  on 
the  input  signal.  There  are  two  approaches  commonly  seen: 
the  first  uses  banapass  filtering  and  Fourier  analysis  in 
the  frequency  domain;  the  second  uses  Linear  Predictive 
Coding  (LPC)  to  analyze  the  signal  in  the  time  domain. 

Feature  extraction  is  the  most  important  processing 
function  in  any  pattern  recognition  system  cf  which  speech 
recognition  systems  form  a  major  subset.  Both  the  spectral 
shape  and  the  time  derivative  of  the  spectral  envelope  are 
measured  over  the  frequency  range  of  interest.  Comoinations 
and  sequences  of  these  measurements  are  used  to  produce  a 
set  cf  32  acoustic  features  which  inclride  such  things   as   a 
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wore  boundary  estirr.ate,  spectral  arrpli  tudes ,  and  formant 
iTequencies  . 

In  most  of  today's  systeirs  the  first  three 
functional  corrponents  have  teen  irTplerr,ented  exclusively  or 
prin-crily  in  hardware  in  order  to  achieve  real  time 
processing.  I  r.  contrast,  the  classification  or  decision 
process  is  usually  implerTiented  in  software  on  a  mini  or 
ricrccomp'Jter.  The  classifier  uses  pattern-matching  logic 
to  compare  the  features  of  the  utterance  with  the  pre-stored 
reference  patterns  and  uses  a  "best-fit  algorithm  to 
determine  the  correct  one.  It  is  also  possible  to  produce  a 
'no-decision  or  reject  v*hen  none  of  the  reference  patterns 
is  close  enough  to  the  utterance.  When  the  classifier  makes 
its  decision,  it  uses  the  number  of  the  best-fit  utterance 
to  select  the  correct  output  character  string  which  it  then 
senas  on  a  serial  interface  to  a  host  computer. 

There  are  two  types  of  errors  that  can  occur  in 
spetcn  recognition.  The  first  is  rejection  or  the  inability 
to  correctly  classify  an  utterance.  The  second,  and  more 
troublesome,  occur  when  the  recognizer  substitutes  one 
utterance  for  another.  Rejection  errors  typically  cause  few 
prcfclems  since  most  recognizers  will  inform  the  user  by  an 
audible  beep  that  an  utterance  was  rejected.  Substitutions 
are  more  difficult  and  the  better  systems  usually  have 
recognition  algorithms  designed  to  reject  rather  than  guess 
at  questionable   words.   The  better  quality  systerrs,  such  as 
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ihe  Threshcld  Technolcgy  6e0  and  6£Z,  have  error  rates  that 
are  quite  acceptable.  In  the  irragery  interpretation 
experiment,  for  example,  recognition  accuracy  was  97%  if 
only  substitutions  were  counted  as  errors.  Iven  if  rejects 
viere  included  in  the  error  counts,  recognition  was  still 
better  than  9i%,  These  figures  compare  quite  favorably  with 
results  obtained  from  rranual  typing.  Results  of  other 
evaluations  have  been  roughly  the  same.  We  can  say  with 
some  certainty,  then,  that  limited  vocabulary,  speaker- 
dependent  voice  input  systems  now  represent  stable  and 
mature  technology  that  can  be  used  in  a  number  of 
applications,  and  certainly  in  the  CNCC. 

C.   VCICI  OUTPUT 

1.   Typical  Applications  of  Voice  Output 

In  contrast  to  voice  input  technology,  the  use  of 
voice  output  is  not  so  well-defined  either  in  terms  of  the 
technology  itself  cr  cf  its  applications,  l^'anuf acturers  of 
voice  response  equipment  nave  yet  to  settle  on  a  common 
techncicgicai  approach  and.  application  outside  the  telephone 
industry  has  been  comparatively  limited.  In  general,  there 
are  three  bread  areas  where  the  use  cf  speech  output  devices 
has  proven  oeneficial.  Before  discussing  the  technology 
further,  it  is  worthwhile  to  loc^  at  these  three  areas  more 
closely. 
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The  first  application  area  iovolves  those 
operations  where  the  telephone  has  always  teen  an  integral 
part  of  day-to-day  operations.  The  most  obvious  exarrple  is 
in  the  phone  industry  itself  where  corrputerized  speech  has 
teen  used  for  some  time  to  perform  functions  that  have 
traditionally  heen  done  by  human  operators  (e.g.  "The  number 
you  have  dialed  is  not  in  service",  etc.)  Voice  response  has 
also  been  used  in  a  nurber  of  private  autoprated  switching 
systerrs  such  as  MCI  EXECUNZT,  a  product  of  MCI 
Telecommunications  Corporation  which  linics  a  number  of 
Cognitronics  661  Speechmakers  to  the  Universal  Switched 
Netwcrii  of  lanray,  Inc.,  a  division  of  Northern  Telecom 
IHef.  14].  Another  type  of  telephone  application  has  been 
the  implementaticL  cf  phone  order-entry  systems.  The  Ford 
Motor  Company's  direct  Order  Entry  System  (TOES),  for 
example,  has  teen  in  operation  since  the  mid-iy70s  and  has 
been  very  well-received  by  Eord  and  Lincoln-Mercury  dealers. 
In  this  application,  the  computerized  speech  output  prompts 
the  dealer  through  the  parts  ordering  process.  Major 
benefits  have  been  "instant  stock  status,  greater  accuracy, 
improved  stocii  turn,  and  ...  overall  improved  customer 
service."  [Ref.  it] 

The  second  broad  application  area  is  the  use  of 
computerized  speech  to  provide  informaticn  traditionally 
supplied  by  a  human  speaKer.  An  example  is  an  experimental 
system   developed   for   the   National   Aeronautics  and  Space 
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Aan-inistration  (NASA)  lesigned  to  test  the  concept  of 
autorratic  approacti  caliouts.  This  system  (called  SYNCAIL) 
used  synthesized  speech  to  generate  the  aperiodic  voice 
reports  given  a  corrtr^ercial  airline  pilot  by  others  in  the 
cocKpit  crew  during  the  approach  and  landing  phases  of 
flight  [Ref.  16:  pp.  4-S]  .  Althoijgh  STNCALL  was  developed 
as  an  experimental  system,  it  did  resv.lt  in  irrprovements  in 
flight  perf orirance  and  was  generally  favored  by  pilots  over 
the  traditional  caliouts  by  the  cockpit  crew,  Irrproverrents 
were  most  marlced  for  approaches  with  high  manual  and  visual 
workload  [Ref.  16:  p.  78].  Variations  of  this  idea  have 
used  speech  to  replace  outputs  usually  generated  by  analog 
or  digital  readout  devices,  such  as  altimeters  end  fuel 
gauges. 

The  third  major  application  area  of  voice  output  is 
as  a  replacement  for  traditional  alarm  devices  such  as 
lights,  bells,  or  sirens.  The  principal  advantage  of  speech 
cutput  in  this  context  is  that  it  conveys  considerably  more 
infornation  than  the  other  alarm  types.  If,  for  example,  a 
computer  operator  hears  a  bell  sound  en  the  computer 
console,  he  first  must  go  to  tne  console  and  read  the  typed 
output  before  identifying  the  problem  and  deciding  on 
corrective  action.  Cn  the  other  hand,  if  he  hears  the 
phrase  "printer  number  two  is  jammed",  he  can  immediately  go 
to  the  device  in  question  and  correct  the  problem.  It  is, 
of  course,  this  application  area  that  we  are  most  interested 
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in  for  the  CNCC.  As  we  aiscussed  in  Section  III,  the  CNCC 
Controller  is  very  busy  and  quite  often  away  from  the  Logger 
teletype.  Replacing,  or  supplernenting,  the  rrore  important 
Logger  TTT  messages  with  voice  response  might  permit  him  to 
do  his  Job  faster  and  more  effectively  and  save  steps  in  the 
process . 

In  our  discussion  of  speech  recognition,  we  briefly 
rentioned  voice  output  as  a  feedback  mechanisrr  in  a  voice 
input  system.  This  might  be  considered  an  auxiliary 
application  of  speech  output  since  its  fundamental  raison 
d'etre  is  to  close  the  interactive  loop  with  the  voice  input 
user.  An  operator  may  be  some  listance  from  the  speech 
recognizer  that  is  processing  bis  utterances.  It  is 
inconvenient  to  have  him  walK  to  a  TTY  to  receive  feedback 
on  his  input  corrmands.  Voice  response  is  a  logical 
candidate  for  the  feedback  mechanism.  In  the  current  thesis 
we  are  focusing  primarily  on  the  alerting  capability  of 
speech  output  although  there  is  limited  use  cf  aural 
feeabeck  in  the  CNCC  model.  The  CNCC  computer  provides  only 
limited  feedback  as  it  stands  today,  making  the  design  of  a 
total  closea-loop  voice  input/output  system  impractical. 
This  subject  deserves  a  good  aeal  more  study  and  would  seem 
to  oe  a  good  approach  to  use  in  the  CNCC  replacement  system. 
The  technology  is  clearly  here;  it  remains  only  to  apply  the 
technology  to  the  design  cf  a  voice-controlled  man-machine 
coFmunica t ion  interface. 
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2 .      Overviev  of  Voice  Output  Technology 

While  deveioprrent  of  speecb  recognition  systems  was 
not  possible  before  the  introduction  of  inexpensive 
electronic  computing  equipirent,  "artificial  speech"  systems 
have  rruch  deeper  historical  roots.  As  early  as  the 
Renaissance,  man  began  to  look  for  ways  to  simulate  the 
actions  of  the  corplex  vocal  mechanism  by  mechanical 
contrivances,  many  of  which  were  quite  clever  in  design 
[Ref.  17:  p. 205].  Fairly  elaborate  speaking  machines  were 
constructed  by  scientific  pioneers  like  Kratzenstein ,  Von 
Kemplen,  and  Sir  Charles  Wheatstone  (no  doubt  more  famous 
for  the  Wheatstone  Bridge/.  These  early  mechanical  efforts 
usually  involvea  the  use  of  oellows  that  generated  varying 
air  currents  through  a  vibrating  reed. 

As  a  boy,  Alexander  Graham  Eell  and  his  brother 
built  a  speaking  automaton  by  making  a  cast  from  a  human 
Skull  and  molding  the  vocal  parts  in  gutta-percha.  One  can 
ccly  speculate  on  the  part  that  this  youthful  endeavor 
played  in  Bell's  later  wcr/:  on  the  telephone.  As  described 
by  Flanagan  [Ref.  17:  pp.  £Z6-2i37]  , 
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All  in  all  it  was  apparently  quite  a  creation  that  could 
utter  vowels,  nasals,  and  a  few  sirrple  phrases. 

Interest  in  rrechanical  analogs  of  the  human  vocal 
system  conti-iued  into  the  twentieth  century.  Later 
cpprcaches  tended  to  depart  from  the  human  physical 
representation  and  turnec  instead  to  devices  such  as  tuning 
fcrics  aLd  organ  pipes.  The  evolution  of  electrical 
technology  accelerated  the  move  away  from  physical  models  in 
the  airection  of  systems  that  generated  sounds  hy  electrical 
tuning  of  amplitude  and  frequency.  H.  V.  Dudley 
demonstrated  his  Vocoder  or  "talking  machine"  at  the  iy39 
World's  rair.  In  the  195Zs  and  62s,  acoustic  engineers  made 
consideratle  improvements  in  analyzing  and  representing  the 
human  vocal  tract.  Advances  in  computer  technology  and  the 
sharp  reductions  in  cost  of  electronic  components  have 
advanced  the  state  of  the  art  to  the  point  where  reasonable 
quality  synthetic  speech  is  available  at  relatively  moderate 
cost . 

The  basic  functional  components  of  a  computer  voice 
response  system  are  shown  in  Figure  10.  The  machine  is 
required  to  speak  a  phrase  typically  expressed  in  spoken  or 
typed  Znglish  text.  The  synthesis  program  must  somehow 
translate  the  original  text  into  a  digital  stream  that 
represents  the  desired  output  including,  if  possible,  the 
proper  duration,  intensity,  and  inflection  for  the 
prescribed   context.   This  stream  is  then  input  to  a  digital 
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speech  synibeslzer  which  speaks"  ihe  message  either  over  a 
leiephone  or  ihrcugh  a  local  speaker.  While  the  functional 
boxes  are  similar  for  all  voice  response  systems,  there  is 
considerable  difference  in  the  way  that  the  synthetic  speech 
is  produced. 

There  are  three  basic  approaches  to  speech 
synthesis?  they  are  distinguished  largely  by  the  storage 
capacity  needed  for  the  vocabulary  and  by  the  complexity  of 
the  control  rules  for  generating  the  speech.  These 
techniques  are:  adaptive  differential  pulse-code  modulation 
(ADPCM),  formant  synthesis,  and  text  (or  phoneme)  synthesis 
[Ref.  17:  pp.  5-6],  Their  respective  data  rates  and 
banawidth  requirements  are  compared  in  Figure  11. 

AIPCM  is  the  simplest  technique.  It  uses  a 
vocabulary  of  human-spoken  words  whose  waveforms  are 
digitally  ceded.  The  method  requires  tradeoffs  between 
signal  quality,  storage  capacity  required  for  the 
vocabulary,  and  the  simipliciiy  of  the  message-generating 
program.  For  message  assembly,  the  synthesizer  retrieves 
the  digitally  coaea  words  from  a  disk  storage  device  and 
applies  them  to  an  ADFCM  decoder  which  produces  the  analog 
output  signal.  With  this  technique  there  is  no  way  to 
control  prosody;  that  is,  no  control  of  vocal  pitch  or 
merging  of  vocal  resonances  is  possicle.  For  this  reason, 
the  most  appropriate  applications  are  those  with  minimal 
possibility  for  semantic  ambiguity.   ATPCM  has  been  used   to 
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generaie  voice  cutpui  in  applicaiions  such  as  equipment 
asserbly,  numeric  readout,  ana  stock  market  quotat ions  [Ref . 
17  :  p  .  6j  . 

The  secona  voice  response  technique,  formant 
synthesis,  uses  a  rethod  in  which  a  word  library  (again 
initially  spoken  by  a  human)  is  analyzed  and  stored  as  the 
tire  variations  of  vocal-tract  resonances  or  formants. 
These  frequency  variations  are  computer  analyzed  and  used  to 
drive  a  digital  filter  whose  input  excitation  is  derived 
from  programmed  rules  for  voice  pitch  and  sound  amplitudes. 
Formant  synthesis  has  been  used  for  the  same  application 
areas  as  ATPCM. 

The  third,  and  in  some  ways  the  most  advanced,  voice 
response  technique  is  called  text  synthesis  or, 
alternatively,  phoneme  synthesis.  It  generates  speech  from 
a  lata  input  operating  at  a  typewriter  rate,  i.e.  about  75 
bits/sec.  Systems  that  use  this  technique  generate  the 
voice  output  entirely  from  stored  rules  and  dictionaries. 
Phoneme  synthesis,  thus,  makes  possible  the  direct 
conversion  of  typed  English  text  to  synthetic  speech.  This 
flexibility  does  not  come  without  cost.  Text  synthesis 
systems  are  invariably  software-intensive.  Routines  are 
required  to  convert  the  text  strings  to  phoneires  and  apply 
prcscdic  rules  to  make  the  speech  sound  "normal".  Such 
software  is  quite  complex  and  usually  can  only  be  written  by 
someone  who  combines  software  development  skills  with  formal 
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trsining  in  Linguistics,  a  corpbination  not  frequently  found. 
In  sriie  of  this  in-posing  software  requi  rerrent ,  phoneire 
synthesis  is  probably  the  best  fcr  computer  applications 
since  it  provides  maxirurr  flexibility  and  has  a  data  rate 
that  is  ccmpatible  with  standard  computer  peripherals.  The 
cevice  used  to  run  the  CNCC  rrodel,  the  VOTRAX  ML-I,  uses  the 
phcnerre  synthesis  approach.  The  field  is  quite  volatile, 
however,  and  new  ana  less  expensive  products  are  being 
intrcduced  all  the  time.  Improvements  in  digital  recording 
and  corpression  techni4ues  and  corrparable  advances  in  the 
parameterized  v»aveform  (fcrmant  synthesis)  method  may  mean 
lEct  teit  synthesis  does  not  represent  the  best  long-term 
alternative  [Ref.  18;  p.  V4] . 

Voice  output  is  available  in  three  forms:  chips, 
Doards,  and  terminals.  Chips  and  boards  are  inexpensive  and 
self-contained  (i.e.  the  speech  waveforms  are  locally 
stored)  thus  they  don't  normally  rely  on  a  host  mainframe. 
They  are  fairly  inflexible,  however,  and  require 
considerable  expertise  to  integrate  into  a  workable  system. 
Prices  fcr  voice  output  terminals  start  around  $500  and  go 
as  high  as  $50,00e;  most  are  priced  under  $10,0^0.  These 
terminals  are  designed  to  connect  directly  to  computers  via 
an  RS-23i:  or  20mA  serial  loop  interface  and  usually  rely  on 
external  memory  for  vocabulary  storage.  Most  of  the 
terminals  use  phoneme  synthesis  to  generate  the  output 
speech.   Because  of  their  ease  of  use  and  greater   overall 
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capebiiities ,    voice    terminals   would   seeir   to   be   more 
appropriate  for  the  CNCC  application  than  chips  or  boards. 
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V.   THE  CNCC  MOTEL 

A.   DESIGN  GOALS  AND  CONSIDERATIONS 

The  CNCC  model  is  a  discrete  event  simulation  that 
FOdels  the  external  behavior  of  the  COINS  Networic  Control 
Center  coT^puter.  It  dees  net  attempt  to  mcdel  the  internal 
operations  cf  the  CNCC,  nor  to  simijlate  the  flow  of  messages 
and  packets  across  the  COINS  II  network:.  Instead,  it 
focuses  on  modeling  the  system  from  the  point-of-view  of  the 
Netviork  Controller,  i.e.  it  simulates  the  output  behavior  of 
the  Logger  TTT  and  the  input  and  output  capabilities  of  the 
Suirnary  TTT.  Design  and  implementation  were  driven  by  the 
fcllcwing  six  design  goals. 


1.  The  model  should  serve  as  a  realistic  simulation  of 
the  external  tehavior  of  the  CNCC  computer  and 
operating  system. 

2.  It  should  provide  a  vehicle  to  demonstrate  the  feasi- 
tility  cf  using  vcice  input  and  output  technology  as 
an  integral  part  of  the  system. 

3.  It  should  be  able  to  serve  as  a  voice  technology 
experimental  testoed.  it  must  be  able  to  run  in 
several  different  operating  modes  and  to  measure 
variations  in  user  response  tires  and  overall 
performance  under  these  different  operating 
environments  . 

4.  The  model  must  be  implemented  on  a  computer  system 
that  is  accessible  tc  the  COINS  PMO. 

z.  It  shoula  be  moduiarly  designed  and  independent,  as 
far  as  possible,  of  any  specific  voice  input  or  output 
hardware  . 
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6.  The  mocei  should  be  extensible  and  easy  lo  rrodify  so 
it  can  serve  as  a  long  term  experimental  testbed  for 
the  CNCC. 


The  Fost  irrportant  of  these  objectives  is  that  the  model 
De  a  realistic  portrayal  of  the  CNCC  environment.  It  is 
essential  that  the  model  behave  in  a  manner  consistent  with 
the  way  that  the  real  CNCC  computer  acts.  For  example,  the 
rodel  must  drive  two  independent  terminal  aevices  ,  one  for 
the  logger  TTT  and  one  for  tne  Summary  TTY.  Processing  of 
operator  commands  should  be  identical  to  the  way  that  the 
CNCC  handles  command  input,  i.e.  the  responses  and  prompts 
rust  be  the  same  as  on  the  real  CNCC.  A  fairly  complete 
subset  cf  the  CNCC  command  language  must  be  supported,  to 
allow  tne  operator  to  perform  the  Networic  Controller 
functions  through  the  model.  Network  events  should  occur  in 
the  model  in  the  same  way  that  they  do  in  real  life. 
Failures  and  errors  in  network  components  are,  of  course, 
not  deterministic.  The  model,  therefore,  should  use 
stochastic  methods  to  generate  the  network  events.  If 
patterns  of  events  were  predictacle,  it  would  be  impossible 
to  discount  the  effects  of  learning  when  running  the  model. 
It  would  be  considerably  more  difficult  to  evaluate  response 
tire  cnanges  under  the  various  operating  moaes. 

Since  the  ncdei's  main  purpose  is  to  explore  the 
feasibility  of  voice  technology,  it  must  be  capable  of 
accepting  input  from  a  speech  recognizer  and  sending  output 
to  a   speech  synthesizer.   Speech  input  is,  as  noted  in  the 
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previous  seciion,  iransparent  to  ibe  host  coirputer  since  the 
recognizer  appears  like  a  terminal  device  en  an  RS-232 
serial  interface;  voice  output,  on  the  other  hand,  is  not 
nearly  so  transparent.  One  cf  the  K:ey  software  routines  in 
the  rrodel  is  a  generalizea  phonerre  output  procedure  that 
interfaces  with  the  VCTRAX  ri-I  synthesizer.  The  routine  is 
tacle-driven  so  it  should  be  reasonably  easy  to  rrodify  it 
for  ether  phonerre  synthesizers.  In  addition  to  the  voice 
output  routine,  we  designed  and  iiriplerrented  a  general- 
purpose  text-tc-speech  program  that  allows  a  user  to  create, 
store,  and  rrodify  phcneire  strings  from  directly  from  English 
text  input. 

One  possible  use  of  the  model  is  to  try  to  quantify 
iirprovements  attributed  to  the  use  of  voice  input  or  output. 
To  10  this,  it  should  have  the  ability  to  measure  user 
response  times  in  at  least  three  modes:  manually  typed  input 
and  printed  Logger  TTT  output;  voice  input  and  printed 
Logger  output;  ana  voice  input  and  output.  By  exarrining  the 
results  of  these  response  time  measurements,  it  may  be 
possible  to  maice  an  assessment  of  response  time  as  a 
function  cf  input  or  output  mode. 

To  have  real  long  term  value,  the  model  should  be  able 
to  te  used  cy  COINS  PMO  and  CNCC  personnel  to  investigate 
voice  technology  design  tradeoffs.  lor  example,  we  may  want 
to  IccK  at  the  effects  cf  different  input  vocabularies  or 
alternate  phrasing  of  output   messages.    The   model   should 
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prcvide  the  i'rarre\*ork  for  studies  of  this  nature.  For  this 
reascn,  the  T.ciei  ¥as  implemented  en  a  PEP-11/70  computer 
running  the  UNIX  operating  syster.  It  should  be  easy  to 
transport  to  one  of  the  COINS  Terminal  Access  Systems. 

modular  design  and  device  independence  carry  with  them 
the  distinct  connotations  cf  motherhood  and  apple  pie. 
Nevertheless,  we  did  make  a  real  effort  to  embody  these 
features  in  the  CNCC  model.  The  program  is  made  up  of  a 
number  of  small,  single-function  routines  and,  except  for 
the  VOTRAX-dependent  cede,  avoids  ties  to  specific  physical 
devices.  The  UNIX  I/C  system,  which  views  all  devices  as 
files,  helps  maintain  tnis  generality.  To  interface  to 
another  voice  output  device  would  require  only  that  a  new 
output  driver  be  written.  The  message  definition  and 
phoneme  retrieval  logic  can  remain  intact. 

The  design  of  the  model  should  permit  extensions  and 
modifications  to  be  made  without  changes  to  the  basic 
software  strLCture.  To  ensure  this,  most  of  the  important 
procedures  are  file  or  tabie-arlven.  Parameters  and 
physical  device  assignments  can  be  changed  at  run  time. 
Acding  new  commands  or  events  requires  only  adding  an  entry 
to  the  appropriate  tatle  and  writing  a  handler  for  the  new 
event.  The  entire  program  is  written  in  DEC  FORTRAN-IV  PIUS 
as  mcdified  for  UNIX  oy  CULC  Inc.  This  comtines  the 
advantages  of  writing  In  a  commonly-icnown  language  with  the 
ability  to  use  many  of  the  basic  features  of  UNIX. 
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E.   EARDlfcARZ:  ANE  SOFTWARE  ENVIRONI^ENT 

The  CNCC  [Todel  operaies  on  a  Digital  Equiprr,ent 
Corporation  (lEC}  PEP-11/70  computer  running  the  UNIX 
operating  system.  The  system  on  which  the  rrodel  was 
developed,  in  the  NFS  C3  laboratory,  uses  a  version  of  UNIX 
supported  hy  Eclt  Eeraaek  and  Newman  (EBN).  BBN  UNIX  is  a 
hybrid  of  the  sixth  and  seventh  editions  of  the  standard 
Western  Electric  UNIX  The  trodei  consists  of  two  cooperating 
processes  both  coded  in  CULC  iORTRAN-IV  PLUS  (F4P).  E4P  is 
a  superset  of  ANSI  standard  FORTRAN  that  provides  access  to 
the  UNIX  I/O  system  and  to  many  cf  the  standard  system  calls 
[Ref.  c0j  .  Since  portability  to  non-UNIX  computer  systems 
vas  net  an  explicit  design  goal,  we  felt  free  to  use  special 
F4P  features  like  byte  variables  and  UNIX  system  calls. 
The  model  should  be  easy  to  install  on  systems  running 
variants  of  UNIX  other  tnan  the  EEN  version. 

In  addition  to  the  PDP-11/70,  the  hardware  suite 
consists  of  two  terminals  connected  to  the  mainframe  via 
serial  RS-232C  interfaces.  In  the  MPS  configuration,  we 
used  two  AIMZ  CRT  terminals  manufactured  by  Lear  Siegler 
Inc.  Any  terminal  that  looks  like  a  teletype  to  UNIX, 
either  bardcopy  or  CRT,  would  work  just  as  well.  Associated 
with  the  Summary  TIT  is  a  ThresholQ  Technology  T-6e0  Speech 
Recognizer  used  for  input  of  voice  commands.  When  operating 
in  voice  input  roae,  the  operator  speaks  short  command 
phrases  to  the  T-600  which  converts  them  to  strings  of  ASCII 
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characiers  accepiabie  ic  the  mcdei 's  commard  interpreier.  A 
list  of  the  operator  utterances  along  with  the  associated 
character  strings  is  given  in  APPENDIX  C.  The  line  to  the 
Logger  TTY  terminates  in  a  VOTRAI  ML-I  Audio  Response 
Systerr.  This  device  norrraily  passes  on  ail  characters  to  an 
Ari^S  connected  to  its  business  equipment  pert.  When  the 
M-I  detects  special  control  characters  in  the  data  stream, 
it  interprets  the  characters  that  fclicw  as  a  series  of 
phoneme  codes  making  up  a  voice  output  message.  The  voice 
ouput  messages  used  fcy  the  model  are  summarized  in  APPENDIX 
D.  A  bloci  diagram  of  the  hardware  configuration  is  shown 
in  Figure  12. 

The  -model's  scftiikare  comprises  two  E4:P  programs,  named 
cncc  and  ttyin.  In  addition,  a  voice  output  editor  (mil)  is 
used  to  generate  the  phoneme  strings  fcr  the  synthesizer. 
«"hen  all  programs  are  considerea,  the  model  involves 
approximately  20,200  executable  FORTRAN  source  language 
statements.  Code  and  supporting  files  occupy  over  1600 
blocH:s  of  R?06  disk:  storage  (about  e00K  bytes).  The  source 
code  for  all  software  is  the  property  of  the  U.S. 
government.  Anyone  interested  in  possible  use  of  the 
programs  should  contact  the  author.  Operating  instructions 
fcr  the  program  can  be  found  in  the  file  cncc. hip.  This 
file  is  include  as  APPENDIX  A  to  this  thesis. 
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C.   FUNCTIONAL  DESIGN 

figure  12  can  serve  as  a  useful  starting  point  for 
aiscLssing  the  functional  design  of  the  CNCC  rrodel.  After 
ini  tializ  ir.g  its  internal  tables  and  parameters,  the  model 
waits  for  either  an  internal  event  to  occur  or  a  user 
command  to  De  entered  or  the  Summary  TTT.  As  events  occur, 
they  normally  generate  messages  on  the  Logger  TTT.  Certain 
messages  are  accompanied  ty  an  auditle  beep  that  serves  as 
an  operator  alarm.  If  voice  output  mode  is  enabled  these 
events  v»ill  produce  a  voice  output  message  in  addition  to 
the  printed  output.  Sore  events,  typically  automatic 
surrmary  reports,  are  printed  on  the  Summary  TTY.  The 
Network  Controller  can  also  influence  events  by  typing 
corranas  (or  speaking  them)  at  the  Summary  TTY.  These 
commands  are  often  in  response  to  previous  Logger  messages 
(for  example,  the  command  to  reload  an  IMP  following  an  IMP 
down  or  IMP  trap  Logger  message).  Figure  13  lists  the 
internally  generated  events  supported  by  the  model.  The 
Networic  Controller  commands  that  are  supported  in  the 
initial  release  of  the  model  are  shown  in  Figure  14. 

The  list  shown  in  Figure  13  accounts  for  the  most 
frequently  occurring  network  events.  For  simplicity,  the 
program  assumes  that  all  component  failures  are 
exponentially  distributed  according  to  some  parameter  value 
for  rear.  Time  between  Failures  (MTEF,.  In  the  runs  of  the 
mocel   conaucted   at   NPS ,   we  used  a  MTBF  for  both  IMPs  and 
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lines  cf  cne  day  (86,4e0  seconds).  We  also  assumed  that 
sore  types  of  failures  are  rr;ore  likely  than  others.  Irror 
ccnditicns  on  a  line,  for  instance,  are  nuch  more  probable 
than  the  line  going  down.  The  program  uses  a  probability 
distriouticn  that  accoLnts  for  the  relative  likelihood  of 
different  events  alon,g  with  eiponentially  distributed  random 
nurroers  to  select  and  schedule  the  next  event  for  each 
coirponent.  The  parareter  for  the  exponential  distrihution 
can  be  mcdified  by  the  user,  at  run  time,  without  changing 
any  prograrr  cede;  the  relative  likelihood  distribution  is 
stored  in  an  internal  table,  however,  and  can  be  changed 
caiy  by  a  program  reccmpliat  ion  and  linic  edit. 

As  can  be  seen  from  Figure  14,  the  model  does  not 
support  ail  cf  the  CNCC  commands.  These  most  commonly  used 
to  respond  to  network  failures,  however,  are  all  included. 
Two  cf  the  commands  are  not  part  of  the  real  CNCC  command 
repertoire,  but  were  implementea  for  user  convenience.  The 
QUIT  corrrand  allows  the  user  to  gracefully  halt  the  model; 
the  LINI  STATUS  change  command  allows  the  user  to  set  the 
status  of  a  given  line  to  UP,  DOWN,  or  LOOPED.  The  command 
interpreter  behaves  exactly  like  the  real  CNCC.  Each 
command  rrust  be  preceded  by  a  question  mark  and  the  operator 
has  only  tc  type  the  characters  needed  to  uniquely  identify 
the  command.  In  response  to  each  commana,  the  system  will 
either  perforr  or  simulate  some  action  and  send  an 
appropriate   response   to   either   the  Summary  or  the  Logger 
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TTY .  The  prograr  will  take  one  of  three  possible  actions: 
(1;  actually  perform  some  service,  such  as  printing  a 
directory  of  files;  (E)  simulate  an  action  and  type  an 
irirediate  response,  such  as  simulating  a  file  deletion;  or 
^3)  use  some  probability  distriDution,  such  as  a  normal 
aistribut ion,  tc  determine  the  completion  time  for  an  action 
that  involves  seme  delay  caused  by  disk  or  communication 
transfers.  For  example,  the  response  to  the  RELOAD  command 
will  be  scheduled  using  a  normal  distribution  with  mean  12 
and  standard  deviation  2  seconds. 

D.   INTERNAL  DiSI(}N 

1 .   Overall  Structure 

The  CNCC  model  is  composed  of  two  cooperating 
processes  that  communicate  ever  a  specially  designed 
Interprocess  Communication  Facility  (IPCF)  .  An  overview  of 
the  model's  process  structure  is  depicted  in  Figure  15.  The 
child  process  (ttyin)  performs  the  single  function  of 
accepting  anc  valiiating  commanas  entered  by  the  operator  at 
the  Summary  TTY.  *hen  a  legal  command  is  recognized,  ttyin 
passes  a  message  to  its  parent  process  (cncc)  that  contains 
ail  information  necessary  tc  execute  (or  simulate)  the 
command.  All  functions  other  than  command  input  are 
performed  by  the  parent.  These  include  scheduling  and 
executing  network  events;  processing  operator  commands 
accepted  by  ttyin;  printing  summary  reports  and  other  output 


Figure  15.   CNCC  Top-Level  Process  Structure 
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on  the  Surrmary  TTYJ  ana  sending  alert  messages  to  the  Logger 
TTY,  including  voice  output  messages  if  speech  output  mode 
is  enabled. 

Before  discussing  the  control  structures  of  the  two 
processes,  it  will  be  useful  to  describe  the  operation  of 
the  IPCI  facility.  IPCF  was  needed  Decause  the  model  could 
not  te  implemented  in  a  single  process.  UNIX  provides  a 
"sleep"  system  call  [Hef.  c0]  that  allows  a  program  to  sleep 
for  some  time  interval,  i.e.  until  some  networic  event  is  to 
be  executed.  The  only  condition  that  will  wake  the  program 
from  a  sleep  is  the  passage  of  the  time  interval  or  a 
special  type  of  software  interrupt  known  as  a  "signal".  A 
program  cannot  simultaneously  sleep  and  accept  TTY  input; 
conversely,  a  program  in  TTY  input  state  can't  te 
interrupted  for  a  time-out.  This  situation  necessitates 
that  command  input  and  event  execution  be  handled  separately 
Dy  different  UNIX  processes.  The  processes,  although 
operating  asynchronously,  do  need  some  way  to  exchange 
information.  The  typical  way  for  processes  to  communicate 
in  LMi  is  by  use  of  the  "pipe"  mechanism.  Use  of  a  pipe 
requires  synchrcnizaiion  between  the  cooperating  processes, 
i.e.  one  process  has  to  be  ready  to  read  what  the  other 
writes  on  the  pipe.  A  pipe,  therefore,  doesn't  really  solve 
tne  original  problem;  it  only  changes  its  form.  What  we  did 
was  implement  a  primitive  form  of  interprocess  communication 
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ihai  allows  the  processes  ic  run  asynchrcncusly ,  but  still 
exchange  inforipation . 

The  approach  that  we  adopted  was  to  use  disk  files 
as  rrailDOTes  written  by  the  sending  process  and  read  by  the 
destination,  ke  used  disK  files  beca^jse  the  UNIX  Large  Core 
Buffer  Area  (LCBA)  facility  which  allows  processes  to  access 
corrrnon  rrain  merrory  was  not  irrplerrented  on  the  NFS  UNIX 
system.  The  system  was  designed  strictly  for  use  by  the 
CNCC  rrodel  and  no  attempt  was  made  to  introduce  much 
generality.  IPC?  is  made  up  of  three  FORTRAN  subroutines: 
S^I^^SG,  RZI^SG,  and  CEEMSG .  SNEMSG  writes  the  message  to  a 
disk  file  named  X?CF##*,  where  ###  is  the  Process  Identifier 
Ifll)  of  the  destination  process  and  then  sends  a  signal  to 
the  destination  process.  Reception  of  this  signal  causes 
the  destination  process  tc  interrupt  its  current  activity 
(usually  sleep)  end  execute  RDt^SG  which  reads  the  message 
from  the  disk  file.  CHKi"^'SG  is  a  routine  that  checks  for  and 
reads  any  messages  that  might  have  arrived  while  the 
aestination  process  had  disabled  IrCi  interrupts,  typically 
when  performing  non-interruptable  activities  such  as  I/O. 
IPCi  provides  coubie-buf f ering  and  is,  thus,  full-duplex;  in 
practice,  however,  it  is  typically  used  to  pass  messages  in 
only  one  direction. 

The  basic  control  structure  of  the  parent  process 
(cncc)  is  shown  in  Figure  Ic.  The  program  is  event  or 
command-driven,  i.e.  it  runs  only   in   response   to   network 
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ever-ts  or  operator  comirands  .  EVCEK  and  EVCMD  both  call  a 
single  dispatching  routine  (PEKFRm)  which  calls  the 
appropriate  handler  for  each  event.  Events  that  require 
operator  action,  e.g.  IMP  DOWN,  are  executed  like  other 
events  but  after  execution  go  on  a  special  table  called  the 
Pending  Action  List  where  they  remain  until  the  correct 
operator  response  is  recognized. 

The  control  structure  of  ttyin  (see  Figure  17)  is 
even  sirrpler.  The  program's  sole  function  is  to  accept 
valid  corrrands  fror  the  Sunrrary  TTY  and  send  an  IPCF  r^essage 
to  cncc  for  each  command  that  it  accepts.  The  only  thing 
that  corrplicates  ttyin  is  the  requirement  that  input  be 
mfcuffered,  i.e.  character-by-character  rather  than  a  line 
at  a  time.  In  normal  UNIX  TTY  I/O,  the  system  buffers  a 
line  at  a  time  and  performs  certain  Iccal  editing  functions 
such  as  recognizing  special  characters  as  delete-character 
and  delete-line  flags.  To  accurately  simulate  the  Summary 
ITT  interface,  ttyin  must  examine  each  character  as  it  is 
typed  and,  consequently,  must  perform  its  own  local  editing 
,see  figure  1&}.  To  do  this,  ttyin  must  operate  in  what,  in 
UNIX  parlance,  is  called  RAW  mode,  where  each  character  is 
passed  as  typed  to  the  application  program.  The  handler 
interprets  ctrl-h  as  the  rubout  character  and  ctrl-u  as  the 
ceiete-iine  flag.  When  processing  the  arguments  of  a 
command,  the  handlers  recognize  the  sentinels  and  escape 
characters  as  defined  in  Reference  3. 
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2.   rata  Siri:ciures 

APPENEIX  3  contains  a  coirplete  list  of  the 
paratreters  and  global  data  structures  used  in  the  rrodel.  In 
this  section,  we  will  examine  a  few  of  the  rrore  irrportant 
ones  since  fariliarity  with  their  contents  and  access 
rrethcds  is  a  prerequisite  for  an  understanding  of  seme  of 
the  progran  logic  that  we  discuss  in  the  next  section.  For 
better  software  nanagement  ,  ail  the  global  data  structures 
ere  defined  external  to  the  executable  code  itself  and  are 
bound  to  the  routines  at  compile  time  hy  use  of  the  INCLUDE 
jacro.  This  insures  that  each  routine  has  an  identical  copy 
of  the  COM^.CN  tlocks  it  needs  and  eliminates  the  bard-to- 
find  Dugs  that  crise  when  this  is  not  the  case.  This 
technique  axso  makes  it  easier  to  change  the  programs,  both 
during  levelopment  and  later  auring  operational  use. 

lor  much  the  same  reason,  we  made  extensive  use  of 
the  JCRTBAN  FARAhETER  statement  to  define  I/O  units,  array 
sizes,  lengths  of  array  entries,  and  other  program 
ccnstants.  This  improves  program  readability  and,  more 
importantly,  simplifies  the  task  of  software  maintenance. 
icr  example,  to  increase  the  number  of  events  that  the  model 
can  support,  it  is  only  necessary  to  change  the  value 
assigned  to  one  of  the  symbolic  constants  (hAXEV)  and 
recompile  the  program.  In  the  discussions  that  follow,  we 
shall  frequently  refer  to  these  parameters  both  by  symbolic 
name  and  by  the  constant  value  that  they  are  assigned  in  the 
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current  version  of  the  programs.  for  clarity,  we  will 
represent  variable  and  pararr-eter  names  in  upper  case,  even 
thcvgh  tiiey  are  in  lever  case  in  the  actual  source  files. 

The  irost  irportant  data  structure  in  the  rrodel  is  an 
array  that  holds  the  list  of  pending  network  events.  This 
array  (IVINTS)  consists  of  four-byte  entries,  one  for  each 
future  event.  EVENTS  is  an  ordered  queue  to  which  events 
are  added  in  decreasing  order  of  scheduled  tirre.  Thus,  the 
last  entry  en  the  list  is  alvays  the  next  event  to  be 
scheduled.  An  event  entry  contains  the  code  for  the  event 
lEVCCDE},  tae  event  subcode  (SUBCOD),  and  the  time  (in 
seconds  since  the  start  of  the  prograrr)  when  the  event  is  to 
occur  (EVTIME).  The  event  codes  are  the  ones  listed  in 
figure  13;  tne  event  suDcoae  will  normally  be  the  number  of 
some  network  component  such  as  an  IMP  or  line.  The 
following  entry  would  trigger  a  message  "IMP  2  is  down"  at 
127  seconds  after  the  start  of  the  program: 


EVCOLE 
11 


SUECOL 
2 


EVTIME 
127 


Associated  with  the  events  list  are  a  number  of  other  global 
\ariaoles.  NEV  is  the  number  of  events  on  the  list;  TEME  is 
the  tine  for  the  neit  event  to  occur,  i.e.  the  EVTIME  for 
the  last  entry  on  EVENTS?  end  TTNE  is  the  time  until  the 
next  event,  ccmputed  by  subtracting  the  current  time  from 
TENE. 
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Sore  events,  for  exairpie  the  "IMP  DOWN"  rressage, 
establish  conditions  that  require  intervention  fcy  the 
Networic  Controller.  Such  events  are  entered  on  the  pending 
actions  list  (PAL)  until  the  correct  operator  response  is 
noted.  When  az  event  is  pending,  the  prograrr  will  repeat 
the  associated  ouput  ressage  every  60  seconds  until  an 
appropriate  cperatcr  response  is  processed.  PAL  is  an 
unordered  array  of  fcur-hyte  entries  structured  identically 
tc  EV2MS .  An  entry  remains  en  PAL  until  sorre  appropriate 
operator  action  resolves  it,  at  which  tine  an  entry  is 
written  in  the  model's  log  file  (cncc.log)  giving  the 
ZVCCDI,  SUBCOr,  and  the  time  in  seconds  that  the  entry  was 
en  the  PAL.  This  file  can  then  be  analyzed  to  see  if 
different  operating  modes  have  any  effect  on  operator 
response  tires. 

There  are  several  data  structures  used  by  the  voice 
output  software.  The  two  that  have  the  most  significance  to 
the  user,  since  their  contents  can  be  changed  at  run  tire, 
are  two  parallel  arrays  that  associate  network  events  with 
nares  of  files  where  phonere  strings  for  voice  output 
messages  are  stored.  The  first,  VOMID,  contains  two-byte 
entries  tbat  aenote  the  ZVCCLZ  and  SUECCD  for  the  current 
event.  These  are  used  as  an  index  into  the  second,  VOMSG, 
which  contains  expression  identifiers  used  by  the  voice 
output  software  to  locate  the  correct  phoneme  string  for 
eacn  message.   These  arrays,  built  from   data   in   the   disJc 
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file  cncc.voc,  can  be  rodified  by  the  user  wiih  any  of  the 
UNIX  text  editors,  figure  ly  shows  the  contents  of  the  file 
as  it  existed  at  NP5  during  the  development  of  the  model. 
The  ccmr^ents  in  the  file  describe  the  structure  and  contents 
of  each  entry. 

There  are  five  tables  used  to  represent  the  topology 
and  status  of  the  CCINS  II  networic.  ISTAT  uses  a  single 
byte  to  denote  the  status  of  each  IMP  in  the  network  using 
the  standard  status  cedes  described  in  Section  III.  LSTAT 
performs  a  similar  role  for  the  subnetwork  corrmunicat  ion 
lines.  l^CDLNS  has  the  same  structure  as  the  topology  table 
Of  the  same  name  in  the  actual  CNCC  (see  Reference  3  for  a 
description).  VHIMP  and  VHNAf-!  contain  one  entry  fcr  each 
host  in  the  network.  A  VHIMP  entry  contains  the  number  of 
the  Ir-P  to  which  the  aost  is  connected*  an  entry  in  VENAM 
contains  the  name  of  the  host  in  ASCII.  The  network  tables 
are  initialized  at  the  start  of  the  program  by  reading  them 
from  diSK.  LSTAT  and  >'CCL.NS  are  in  the  file  coins.net; 
ISTAT  in  coins. imp;  and  VHirP  and  VHNAM  in  coins. host. 

There  is  only  one  important  data  structure  used  by 
ttyin,  a  table  defined  locally  in  the  command  handler.  C^!DS 
is  a  table  that  contains  a  four-byte  entry  for  each  operator 
command.  The  first  byte  is  the  number  of  characters  in  the 
command;  the  remai.ider  contain  the  characters  in  the  command 
mnemonic. 
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3.   Basic  Evem  Handling  Lc^ic 

CNCC  is  entirely  event-driven  in  the  sense  that  in 
the  absence  of  events  to  execute,  it  would  sleep  forever. 
The  mrael  adepts  a  very  ^-eneralized  aefinition  cf  "event"; 
an/  stimulus,  whether  internal  or  external,  is  considered  an 
event  under  this  definition.  At  the  execution  level,  the 
event  handlers  perform  their  functions  without  regard  to 
whether  the  stimulus  came  from  inside  the  program  or  from 
the  Network  Controller.  For  purposes  of  discussion, 
however,  we  can  categorize  the  events  into  three  dread 
groupings.  In  the  first  group  ere  those  events  that  ere 
scheduled  au  torra  tically ,  either  at  initialization  tirre  or 
auring  operation?  in  the  second  are  the  responses  to 
operator  commands;  and  in  the  third  is  a  hybrid  set  of 
events  that  ccTtines  features  of  the  other  two. 

The  first  set  consists  essentially  of  those  networic 
events  shewn  in  figure  13  with  the  addition  that  certain 
sumnary  reports,  usually  produced  only  on  lemend,  are 
scneduied  at  the  start  of  the  program  and  later  output 
automatically  et  the  proper  tire.  This  illustrates  the 
separation  of  the  scheduling  from  execution  that  imparts  a 
great  deal  of  generality  tc  the  event  handling  routines. 
Typically  this  first  set  of  events  involves  error  conditions 
in  seme  networic  component,  such  as  an  ir^P,  a  line,  or  a 
host.  At  the  start  of  the  program,  an  event  is  scheduled 
for  each   netwcrK:   ccmpcnent.   When   this   event   is   later 
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execuiea,  a  nev  event  is  selected  and  scheduled.  Both  the 
specific  event  and  the  tire  for  the  it  to  occur  are 
determined  Dy  the  use  of  hcnte  Carlo  techniques.  The 
particular  event  is  selected  by  corparing  randorr  nurrbers 
from  a  uniform  distribution  against  a  table  that  gives  the 
currulative  probaoility  distribution  for  the  events  of  a 
corponent  type.  There  are  separate  tables  for  IMPs  and 
lines.  The  prograrr  inaij:es  the  assumption  that  the  time 
between  component  failures  is  distributed  exponentially  with 
seme  mean  time  between  failures  ((^iTBi)  as  the  distribution 
parareter.  MTEFs  are  defined  separately  for  IMPs  and  lines 
anl  can  ce  adjusted  at  runtime  by  changing  the  values  in  the 
file  cncc.ini.  The  UNIX  system  only  generates  random 
nurrbers  from  a  unifcrm(0,l/  distribution.  The  program 
transforms  a  uniformly  distributed  random  number  (y)  to  an 
exponentially  distributed  number  (t)  by  the  formula 

-in(y) 

t  =   

MTBF 

Analytic  justification  for  this  formula  is  presented  by 
aordon  [Ref.  21:  pp.  152-153]. 

Operator  commands  are  executed  on  demand  so  there  is 
norrally  no  scaeauiing  function  to  perform.  Typically,  the 
program  will  respond  immediately  to  operator  interrupts  by 
performing  some  function  and  displaying  the  results  on  the 
Summary  TTT.  For  certain  types  of  events,  these  that 
require   some   time  period  to  complete,  a  different  strategy 
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is  required.  Ihe  test  way  to  descrice  this  sirategy  is  ic 
consiaer  an  exarple. 

Assume  inai  you  are  the  aeiwork  controller  and  you 
want  to  send  some  local  file  to  another  COIN'S  host,  say 
SCLIS.  You  would  type  or  speak  the  proper  corrmand  and 
supporting  parameters  at  the  Summary  TTY .  At  some  time  in 
the  future  you  would  expect  to  receive  notification  that  the 
transfer  was  successful  vcr  perhaps  unsuccessful).  The  time 
to  complete  the  transfer  is  a  function  of  three  variahles: 
the  size  of  the  file,  disk  transfer  time,  and  communications 
transfer  time.  The  program  first  determines  a  figure  for 
the  size  of  the  file  (in  512-byte  blocks)  using  a  number 
from  a  uniform(12,  10B)  distri oution.  Then,  using  constant 
values  for  average  aisk  transfer  time  (50  ms)  and 
comrunica t ion  throughput  (50K  bits/sec),  the  program 
computes  a  value  for  average  transfer  time.  This  value  is 
tnen  used  as  the  mean  of  a  normal  distribution  whose 
standard  deviation  is  approximated  as  2Z%  of  the  mean.  A 
uniform  random  number  is  then  generated  and  transformed  into 
tnis  normal  aistribution  using  an  algorithm  described  by 
&crdcn  [Ref.  21:  py.    Itc-lty] . 

This  number  is  then  usea  as  the  time  to  schedule  the 
ccmpleticn  of  the  event.  The  completion  event  uses  the  same 
event  code  as  the  original  operator  command,  in  this  case 
ZVCODE  3;  to  distinguish  between  the  two  states,  the  SUBCOD 
lield  is  made  negative.   When  the  event  hanaler   is   called, 
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it  checks  the  SUECOE  ana,  if  it  is  negative,  knows  that  the 
event  has  teen  ccmpieted.  It  will  then  output  the 
appropriate  rr^essage.  This  saue  logic  is  used  hy  a  nuiT,ter  of 
routines  in  the  model,  specifically  the  handlers  for  the 
DUhP,  RIIOAD,  SZND,  and  BDCST  comrrands  as  well  es  the  event 
handler  for  the  VIBTUAI-HGST-DUWN  event. 
4.   Voice  Output  Software 

There  are  two  parts  to  the  voice  output  software 
developed  for  the  model.  These  parts  correspond  to  the  two 
steps  involved  in  producing  synthesized  speech.  The  first 
step  in  the  process  is  tc  convert  the  desired  message  text 
into  phoneme  strings  that  are  recognizable  by  the 
synthesizer.  The  second  is  the  recall  and  use  of  these 
strings  as  requirea  cy  an  application  program.  In  a  direct 
texi-to-sreech  syster  these  two  steps  would  be  rrerged;  we 
prefer  tc  thinit  cf  them  as  distinct  operations 

The  first  stage  of  the  process  is  supported  by  an 
interactive  :2Xt-t o-speech  program  called  rrll.  This  program 
accepts  English  text  strings  from  the  terminal,  converts 
them  to  phoneme  sequences,  stores  the  sequences  in  a  disk 
file,  ana  sends  them  to  the  synthesizer  to  be  spoken.  The 
program  then  allows  the  user  to  iteratively  refine  the 
sequences  using  a  full-screen  text  editor.  The  user  can 
selectively  tune  the  output  strings  ty  adding,  deleting,  or 
changing  phonemes  or  modifying  rate  and  inflection  levels. 
Usually  after  a   few  iterations,  the  result  will  be  fairly 
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intelligible  speech  ihei  can  be  reproduced  by  an  application 
program. 

The  text-t c-pacneme  conversion  routines  were 
orifeinally  developed  for  the  VAX-11/780  at  The  Naval 
Undersea  Systems  Center  vNUSC;  in  Newport,  R.I.;  they  were 
converted  to  UNIX  F4p  by  the  author.  The  conversion 
algcrithm  uses  a  set  of  rules  that  maps  letters,  syllables, 
or  words  into  strings  of  phonemes.  The  particular 
in-pleirentaticn  supports  the  VOTHAX  ML-I ;  the  design, 
however,  is  device-independent,  since  the  text-to-phoneme 
conversion  is  achieved  "0/  a  two-stage  transformation 
process.  Text  is  first  converted  to  phoneme  sequences  from 
the  International  Phonetic  Alphabet  (IPi>)  which  is  an 
accepted  standard  of  linguists  and  phcnologists .  A  second 
routine  perforrrs  ttie  device-dependent  conversion  into  the 
M-I  phoneme  codes.  It  is  lively,  then,  that  the  program 
would  be  fairly  easy  to  adapt  to  other  voice  output  devices. 

Zach  output  message  is  assigned  a  unique  name  of 
seven  or  fewer  characters.  The  messages  are  stored  in 
separate  disic  files  tc  facilitate  eciting  and  recall,  e.g.  a 
ressage  r.amec  "crash"  is  stored  in  a  file  named  "crash.mil." 
A  library  of  xCRTRAN-cal iaole  subroutines  allows  application 
programs  to  recall  and  output  these  messages  on  demand.  The 
model  uses  the  VCrSG  table,  described  earlier,  tc  select  the 
narre  of  the  desirei  message  and  send  it  to  the  synthesizer. 
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2.   PHELir^INARY  RESULTS 

Our  intention  in  building  the  CNCC  model  was  primarily 
10  create  a  training  and  learning  vehicle  that  right  help  us 
tetter  urderstand  the  CNCC  application  and  the  pcssltle 
utility  of  voice  technology.  We  were  not  looking  to  develop 
a  fcrrral  method  I'cr  quantifying  this  utility.  The  only 
variable  that  the  prcgrarr  attempts  to  measure  is  the  time  it 
taies  for  the  NetwcrK  Ccntroiler  to  respond  to  certain 
events.  As  we  noted  earlier,  a  formal  evaluation  experiment 
v.as  not  a  part  of  cur  overall  strategy.  Despite  this,  we 
decided  to  use  the  model  to  obtain  some  idea  of  the  way  that 
different  input  and  output  modes  affect  operator  response 
time  and  productivity. 

The  methodology  that  we  adopted  was  to  run  the  model  for 
approximately  two-hour  periods  under  three  different 
environments.  ke  first  ran  in  a  mode  where  input  ccmmar.ds 
were  typed  manually  and  alert  messages  were  displayed  on  the 
Logger  TTT,  accompanied  by  tells  that  functioned  as  audible 
alarms.  Next,  we  used  the  sane  output  mode  out  spoke  the 
commanas  to  an  automatic  speech  recognition  device  rather 
taan  typing  them  manually,  i'inally,  we  added  voice  output 
to  this  configuration  oy  sending  the  alert  messages  to  the 
^.L-I  speech  synthesizer  to  ce  spoken  aloud.  While  the  model 
was  Tinning,  the  author,  playing  the  role  of  the  Network 
Controller,  worked  on  a  parallel  tasK  a  short  distance  from 
the  Sbmmary  ana   Logger   TTYs.    (This   parallel   task  was, 
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inciaeataiiy ,  the  iroauciion  of  ihis  thesis.)  When  ihe  rrodel 
issijed  an  aiert  that  called  fcr  operator  action,  he  would 
issue  the  appropriate  connmand  by  either  typing  or  speaking 
it,  depending  en  the  particular  operating  environment. 

The  results,  in  terrr.s  of  operator  response  tiire,  are 
surrmarized  in  Figure  Z2.  As  the  results  show,  there  was  a 
draratic  reduction  in  average  response  tire  when  we  replaced 
typed  commands  with  spoKen  ones  and  an  adaitional,  but  less 
draratic,  reduction  when  we  added  voice  output.  The  amount 
cf  'variability  in  response  time,  as  measured  by  the  standard 
deviation,  follows  c  similcr  pattern. 

Perhaps  rore  meaningful  would  be  seme  indication, 
however  subjective,  cf  the  effects  cf  the  different  modes  en 
parallel-task  proauctivi ty .  In  the  first  scenario,  very 
little  was  ccccmplished  on  the  parallel  tasK  since  the 
operator  seemed  to  be  constantly  moving  from  his  text- 
editing  work  station  to  either  the  Summary  cr  the  Logger 
TTI.  The  actual  duration  of  a  typical  interruption  vas 
generally  fairly  crief.  The  effect,  however,  was  usually 
much  more  significant  since  the  time  would  te  long  enough  to 
cause  the  cperatcr  tc  lose  his  train  cf  thcught  by  tr.e  time 
he  returned  to  the  task.  In  the  second  operating  moae, 
response  times  •ere  substantially  better;  but  the 
improvement  did  not  carry  o\er  as  much  to  the  parallel  task. 
There  was  still  a  need  to  walk  to  the  Logger  TTY  and  read 
the  alarm  message   before   issuing   the  proper   recovery 
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OPERATING  MODES 

1.  Manual  input,  printed  output. 

2.  Speech  input,  printed  output. 

3.  Speech  input,  speech  output. 

figure  2Z.   Cperator  Response  Tinges  (in  secoods) 
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conTdna.  In  the  third  situation,  the  interruptions  seered 
to  have  much  less  cf  an  eri'ect.  There  vas  cc  need  for  the 
operator  to  rove  away  from  the  teririnel  where  he  was  doing 
his  text-edi tiag.  He  could  hear  the  error  messages  and 
could  quicKiy  fcr'^uiate  a  response,  speaK  the  appropriate 
corrective  corrnrand,  and  return  to  work. 

These  results  ^ust  certainly  be  viewed  with  a  cautious 
eye.  First  or  ail,  since  no  forrial  experirrent  was 
concucted,  even  tne  quantitative  results  lack  the  solidity 
of  those  that  result  frotr  a  controlled  and  replicated 
experirent.  They  perrrit  no  inference  as  to  the  statistical 
significance  cf  any  cf  the  variaole  factors.  Secondly,  the 
subjective  cofr.ments  or.  paral  lei-ta  sij:  productivity  have  to  be 
considered  unsutstantiated  ocservaticns  from  a  pcssitly 
Biased  source,  i.e.  the  author.  Lastly,  it  is  not  certain 
that  faster  response  tire  and  cetter  parallel  productivity 
5re,  oy  themselves,  all  that  important.  The  Network 
Ccr.trciier  needs  to  respond  quicicly  to  netwcrK:  events,  tut 
is  there  really  a  suhstantive  difference  between  35  seconds 
and  E  seconds?  Is  overall  COINS  operation  significantly 
improved  by  such  a  response-tire  reduction?  Irrproved 
parallel  productivity  implies  that  overall  operator 
effectiveness  will  oe  increased,  but  is  the  irrprovemer.  t 
sufficient  to  justify  the  cost  of  the  voice  technology? 
These  questions  cannot  be  answered  by  merely  running  a  model 
ana   examining   the   results.    They   rec^uire  a   careful 
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•randoeneni  appraisal  bel'cre  a  decisicn  can  ce  reached  that 
voice  technology  in  the  CKCC  is  or  is  not  cost-effective. 
Presumably,  the  principal  value  cf  the  CNCC  mcdel  is  that  it 
can  play  a  useful  role  in  that  asses srrent. 
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V I  .   APPPOACHZS  TO  Ii^  PIZMINTATICN 

A.   GSNIRAL 

Having  derrons iraied  ccth  ihe  appii  ca  bility  and  ihe 
feasibility  cf  voice  technclcgy  in  ihe  CNCC,  we  turn  new  tc 
a  discussion  ot  hew  this  technolOp^y  iri^ht  be  installed  in 
the  existing  Network:  Ccntrci  Center.  In  this  section  we 
will  consider  both  the  ar^roxirrate  cost  and  the  steps 
invcived  in  irrpieTientat  icn .  Althcugh  ve  vill  examine  the 
rrerits  ar.t  shcrtcoFi  r,^s  of  existing  systerrs,  we  stop  short 
of  reccpnmendin^  the  hardware  cf  any  specific  manufacturer. 
The  corrercial  rarket  for  voice  technology  is  hig'ily 
volatile  and  the  system  that  seems  the  best  choice  now  mignt 
not  ofc  best  in  six  months.  If  it  is  lecidei  to  £0  ahead 
'*  i  th  voice  input  cr  output  for  the  CNCC,  a  comparison  that 
explores  the  tradeoffs  cetween  cost  '='na  capaoility  will  be 
necessary  before  buying  specific  hardvare.  Presumably,  the 
discussions  in  this  section  can  serve  as  a  starting  point 
for  this  effort.  The  ultimate  aecision  on  the  utility  of 
voice  technology  viill.of  course,  be  cased  on  its  cost- 
effectiveness  to  me   COINS  project  as  a  whole. 

Voice  input  and  output  are  related  tut,  ir  many  ways, 
entirely  aifferent  teci^nologies  that  raise  different 
implementation  questions.  '*e  will  therefore  address  them 
separately   in   this   section.    We  will   first  looic  at  the 
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irpierenia t ion  of  Autorraiic  Speecb  Recognition,  where  we 
have  accumiiidied  a  f?Gcd  deal  cf  experience  ard  vhere 
irplementat  ion  is  straight  forward.  We  then  rrove  on  tc  the 
rurkier  area  of  speech  output  where  we  have  iruch  less  direct 
experience  ard  where  inpiementat  ion  is  ^lore  involved,  with 
a  nurter  of  different  strate^-ies  availatle. 

B.   VCICI  INPUT 

1 .   CNCC  Voice  Input  P.equirerren  t  s 

Instaiiaticn  cf  ASH  devices  is  so  sirple  as  to  naK:e 
the  terrr  '"implenentation"  sound  a  little  pretentious.  All 
that  is  involved  is  connecting  the  recrsnizer  tc  tlie  host 
(in  this  case  the  CNCC)  via  an  HS-c32  interface,  developing 
and  traini^^  the  vocacuiary,  and  proceeding  to  use  the 
system.  The  vocaDulary  tnat  we  usea  to  test  the  CNCC  rrodel 
can  serve  as  the  casis  for  t-uiiding  the  one  tc  be  used  In 
actual  operation.  The  rain  problerr  is  in  selecting  the 
particular  syster  to  use.  This  process,  not  surprisingly, 
involves  the  classical  tradeoff  oetveen  cost  and  capability. 
Cur  experience  tc  date  suggests  that  a  speech 
recognizer  used  in  the  CNCC  should  have  the  following 
rrinirai  set  of  features: 

—  support  a  vocabulary  cf  at  least  120  utterances? 

—  be  acle  to  operate  in  a  moderately  noisy  environrrent; 
--  support  a  wireless  transmission  capability;  and 

—  have  recognition  accuracy  of  over  ir'5%. 
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The  lest  vocabulary  thai  ve  used  with  the  CNCC  rriodel 
ccntdins  atcui  £t:  Vitterances.  At  least  thirteen  cl'  tnese, 
however,  would  not  be  used  in  the  CNCC  in  actual  operation. 
Exarples  include:  "Step  the  Model",  "Chan^^e  directory  to 
CCINS"  and  several  others  that  were  included  rore  for 
ccr.ver.ience  than  cperaticnal  necessity.  Ve  did  r.ct 
irrplerrent  the  entire  set  of  CNCC  comriands  in  the  rrodel  and 
there  will  te  a  nurrber  of  utterances  that  we  will 
undcuttedlv  wart  to  edd.  A  lez-ut terence  vocabulary  shor]d 
te  viewed  as  a  10'*er-round ;  150  or  kiee  ri^ht  be  really  nore 
practical  to  allow  for  vocabulary  expsnsion. 

Corr.puter  centers  always  ,senerate  sere  arount  of 
bacKground  noise.  The  banein^  of  printers,  the  whirr  of  air 
conditioners,  and  the  opening  and  closing  of  doors  and 
drawers  are  heard  routinely  in  any  ALP  operations  area.  It 
is  necessary,  therefore,  that  the  speech  recoi?nition  systerr 
use  sorre  technique  to  filter  out  the  unwanted  bac«:e"round 
ncise.  Usually  this  is  accomplished  by  use  of  a  siecially- 
desi^ned  ncise-cancellins  micrcphcne. 

As  we  pointed  out  earlier,  the  Netvork  Controller  is 
frequently  away  frcr  the  Surrirary  TTY  consrie.  It  would  be 
inconvenient  for  him  to  return  to  the  console  to  enter  voice 
input  ccrrrrands.  It  would  be  equally  inccnveniert  ,  as  veil 
as  unsafe,  to  use  a  headset  with  wires  trailing  back  to  the 
voice  input  unit.  There  is  a  definite  requireTent, 
tnerefore,  for   some   type   of   radio   transrritter  to  pass 
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signals  t'vcm  the  nicrcphcne  lo  ihe  recoerizer.  This  will 
perrit  convenient  and  safe  operation  at  sorre  distance  from 
th9  Sun-.rrary  TTY. 

A  reascnaDle  level  cl"  recco:niticn  accuracy  is 
essential  for  successf'ul  operational  use.  To  be  beneficial, 
speech  recognition  should  reduce  tne  number  cf  input  errors 
that  would  occur  If  corrp-ands  where  entered  rnanualiy.  A 
nurrfcer  of  manufacturers  of  mcderately-priced  recognizers 
advertise  recognition  rates  in  the  bt%  range.  These  figures 
can  te  misleading';,  however,  trecause  recc^niticn  accuracy  is 
very  much  a  function  of  vocabulary  design  and  experience  of 
the  users.  Marketing  brochures,  tberefore,  should  be  lool-^ed 
at  rather  ca'^efuliy,  the  best  guarantee  of  recognition 
accuracy  being  a  test  with  the  aesired  vocabulary.  Based  on 
experience  with  the  CNCC  model,  there  should  be  little 
problem  in  attaining  an  acceptable  accuracy  rate  with 
several  cf  the  recognizers  available  today.  It  is  when  one 
:egins  to  look  for  error  rates  of  1%  or  less  that  the  slopes 
cf  the  cost  curves  become  very  steep. 

Several  authors  have  commented  on  an  interesting 
tehaviorai  phenomenon  exnitited  by  people  ceing  introduced 
to  voice  input  for  the  first  tirre.  Users  are  nruch  more 
critical  of  voice  input  errors  than  of  errors  in  typing. 
Pcrck  [Ref.  5:  pp.  Zl-c2]  noted  that  when  he  demonstrated 
various  software  products  at  the  Naval  Postgraauate  School, 
users  accepted  his  fre^iuent  typing  errors   as   a   matter   cf 
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course.    However,   if   he   raae  one  error  while  using  voice 

input  the  view  cl'ten  expressed  was,  "voice   irput   is   nice, 

but   it's   cbviousiy   not  perfect  and  has  a  long  way  to  go." 

'A'hile  we  cfcvicusly  want  an  ASR  systen  tc  be  as   accurate   as 

possible,    we   should  guard   against   adopting  a   "doutle 

standard"  between  speech  and  typing. 

2.   Possicle  Voice  Recognition  Systers 
fc  -        II    ■ 

In  exarrining  alternative  voice  recognition  systeps 
available  in  the  ccrrrercial  rarket,  we  focused  on  what  could 
te  considered  the  [riddle  range  of  voice  recognition 
products ( roughly  $£,000  tc  $£0,000  for  a  suitably  equipped 
syster)  and  tended  to  ignore  systems  at  either  end  of  the 
price  spectru.T.  Scott  I  qs  trurrents  ,  for  exarrple,  rrarkets  a 
corplete  voice  recognition  systen-  (the  Vet/2)  that  runs  with 
either  the  Apple  II  or  tne  TR£-e0  for  about  $^00  [Ref.  ?2: 
p.  106].  The  eviience  so  far  suggests  that  the  Scott 
recognizer  and  the  ohsr  low-priced  systerrs  do  not  rreet 
either  the  vocaculary  size  requirerent  or  the  acceptable 
accuracy  level.  At  the  high  end  of  the  spectrurr,  Verbex  end 
Nippcn  Zlectric  both  ranufacture  systerrs  with  excellent 
accuracy  ratings  that  are  designed  to  handle  lirrited 
connected  speech.  These  systers  retail  for  over  $65,000, 
however,  a  price  that  seerrs  ruch  too  expensive  for  the  CNCC 
application . 

Of  the  many  commercially  available  speech 
recognition  systers  in  the  desired  price  range,  there  ere  at 
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least  two  that  precise  good  siipport  for  the  CNCC 
appiicaticn.  These  are  the  Threshold  T-e00,  n-ar.v fact v red  by 
Threshold  Technology  of  Celran  N.J.  and  the  Interstate  VFM, 
produced  ty  Interstate  Electronics  Corporation  of  Anahein, 
Ca.  The  reader  ray  gain  sorre  insight  into  the  rapidity  of 
change  ir.  the  voice  technology  rraricet  by  the  fcllcwinp-*  Item. 
When  this  section  was  first  heing  drafted,  there  were  three 
systems  that  seemed  to  have  potential  for  the  CNCC 
application.  When  the  author  phoned  the  third  (unnamed) 
company  for  informaticn,  he  was  informed  that  the  compary, 
previously  regardea  as  one  of  the  leaders  in  the  field,  was 
no  longer  making  voice  recognition  equipment. 

The  Threshold-€00  was  the  voice  recognizer  used  with 
the  CNCC  rcdel  in  the  NPS  laDoratrry.  It  was  quite  easy  to 
use  and  performed  very  reliably.  The  T-600  systerr  is  made 
up  of  a  Shure  Sf'-l?  ncise-carcell  ing  micrrphcne,  an  Ann 
Arbor  large  character  display  and  operator  console,  e  tape 
cartridge  unit,  an  analog  speech  preprocessor,  an  ISI-11 
microcomputer,  end  a  serial  Ri3-222C  compatible  input/output 
interface.  Aq  Jf^,  wireless  transmitter  is  available  for  an 
additional  charge  of  about  ^5200.  The  recognizer  will 
accept  as  many  as  256  discrete  utterances  of  up  to  two 
seconds  in  duration.  A  pause  of  at  least  120  ms.  is 
required    oetween   utterances.    The   processing   time   to 
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recognize  an  uttercnce  aepends  on  the  size  of  the  vocebulary 
but  v^iii  usually  be  no  tr.ore  than  25?  rrs.  [Hef.  23] 

In  lerrrs  cf  performance,  the  T-e00  is  one  of  the 
best  in  the  fieid.  The  founder  and  President  of  the 
ccTpany,  Thomas  B.  Martin,  is  one  of  the  pioneers  in 
aeveloping  practical  speech  recognition  systerrs.  The 
ccrpany  has  a  wide  and  varied  customer  base  and  its  prcdrcts 
have  oeen  used  in  almost  every  conceivable  application.  In 
addition,  the  T-60e  has  been  used  i  r.  several  intelligence 
and  Cotrrrand  and  Control  contexts  and  the  experience  gained 
from  these  operations  sliould  be  transferable  to  an 
application  such  as  the  CNCC.  All  in  all  the  T-e00 
represents  mature  lechnclcgy  from  a  stable  and  experienced 
company.  The  principal  disadvantage  of  the  T-e00  is  its 
fairly  hish  cost  in  comparison  to  some  cf  the  other 
recofe-nizers  on  the  marxet.  A  fully  equipped  T-e00,  with  the 
wireless  ^M  transmitter,  will  cost  in  the  neighborhood  of 
515,000. 

The  Interstate  Voice  Response  ^oduie  (VRM),  by 
contrast,  can  be  purchased  for  as  little  as  55,000, 
depending  en  the  options  desired.  The  conpany  does  not 
explicitly  advertise  an  in  transmitter,  but  assuming  that 
one  were  available  at  a  price  ccmparabie  to  that  of  the 
Threshold  wireless  system  (about  $5,000),  the  total  cost  of 
an  Interstate  system  would  be  roughly  510,000,  about  50% 
less   than   for   the   T-500.    The  Interstate  Voice  terminal 
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;Voterm},  comDines  e  vreyooard,  display,  48K  bytes  of  Random 
Access  ^eFQvy  (HA(^),  a  Z6e  microprocessor,  and  a  105^(^-byte 
fioppy-disK  drive.  The  Voterm  will  recognize  up  to  100 
speaker-dependent  discrete  utterances.  An  additional 
feature  vortn  noting  is  a  board  (available  for  about  $1000) 
that  provides  a  voice  response  capability.  The  board,  which 
uses  VCTRAX's  SC-Sl  chip,  supports  500  words  stored  in 
rerrory  and  the  ability  to  progrer  about  l?e0  additional 
words  . 

While  it  possesses  sore  attractive  and  potentially 
useful  features,  the  VRh;  dees  have  at  least  twc  possible 
drawbacks.  First,  the  100  word  vocabulary  may  leave 
insufficient  rccm  for  expansion  and  might  not  provide  enough 
phrases  for  the  CNCC  operation.  Second,  there  is  littlF 
experience  within  the  C3  or  intelligence  communities  with 
the  VRr:.  The  author  did  visit  an  experimental  effort  at 
NASA's  Ames  Research  Center  that  used  the  Interstate  Voterm. 
however,  this  particular  effort  used  a  very  small  vocabulary 
(only  four  worcs)  and  thus  it  is  hard  to  draw  a  comparison 
T»ith  the  CNCC  where  a  much  larger  vccaculary  is  required. 
The  NFS  Hunan  Factors  laboratory  has  plans  to  purchase  a 
Voterm  this  spring,  and  their  experience  may  help  us  to 
evaluate  the  utility  of  the  Interstate  VH!^  in  the  CNCC. 
3.   Potential  Areas  cf  Concern 

fost  of  cur  discussion  in  this  thesis  has  emphasized 
the  positive  aspects  cf  Automatic  Speech  Recognition.   There 
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is  no  question  that  we  believe  it  to  de  a  technique  that  can 
assist  the  Network  Controller  in  pert'orrring  his  duties  rore 
effectively  ana  conveniently.  Nonetheless,  as  with  any 
technolosy  that  introduces  funcan-ientai  changes  in  operating 
pr':'cedures ,  it  is  not  withcvt  some  risic.  There  seem  to  be 
two  issues  that  should  be  carefully  considered  before 
proceeding  i*ith  installation  of  a  speech  recognition  systerr. 
^e  will  discuss  each  cf  then  briefly  here,  but  they  clearly 
warrant  further  consideration  oy  the  CCINS  PMC  and  CNCC 
rancg;ement . 

The  first  question  concerns  the  use  cf  voice 
recognition  by  yirre  than  one  speaK:er  on  each  shift.  As  we 
have  discussed  elsewhere  in  this  thesis,  voice  recognition 
systems  are  speaicer-dependent  and  must  be  trained  by  each 
user  of  the  syster.  In  other  words,  each  Network  Controller 
would  train  the  system  with  his  voice  patter'^s  and  then 
store  these  patterns  on  a  small  cassette.  At  the  start  of  a 
snift,  the  Ccntrciier  would  read  the  cassette  into  the 
merrory  of  the  recognition  system  (which  takes  less  than  a 
rinute^  and  would  then  be  ready  to  issue  voice  commands. 
This  scenario  presumes,  however,  that  only  one  'operator  per 
shift  will  use  the  voice  equipment.  If  this  assunption  is 
not  valid,  seme  alternate  procedure  will  have  to  be  adopted. 
Cne  possibility,  if  the  vocabulary  is  srall  encugh,  is  to 
train  mere  than  cne  operator  on  a  single  tape.  This 
approach   has   teen   tried   informally   at   NFS   and  appears 
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prcTising.  Depending  en  the  size  cf  the  vocabulary  and  the 
ingenuity  used  to  design  it,  we  plight  be  able  to  store  as 
ran/  as  three  sets  of  voice  patterns  on  a  single  tape 
cassette.  The  problem  is  net  insurmountable;  it  simply  has 
to  te  addressed  before  voice  recognition  equipment  is 
selected  and  installed. 

The  secona  concern  stems  from  the  feet  that  our 
stud/  of  the  CNCC  *as  conducted  second-hand  at  a  distance  of 
2000  miles.  We  have  attempted  to  digest  and  understand  all 
the  operating  procedures  for  the  CNCC.  We  are  not  naive 
enough  to  believe,  however,  that  manuals  of  operating 
procedures  ai'-ays  accurately  mirror  the  operation  tbat  they 
purport  to  describe.  Fcr  many  of  the  situation?  that  arise 
in  the  COINS  II  network,  the  Cr:CC  operators  manual 
prescribes  alternative  courses  of  action.  i'cr  example, 
corrective  proceaures  can  often  be  initiated  from  eitber  the 
Sum'T-ary  TTT  using  the  CNCC  command  language  cr  the  Master 
II^P  using  a  different  set  of  commands.  Cur  analysis  and 
subsequent  model  have  --ade  the,  perhaps  simplistic, 
assumption  of  a  single  data  entry  point  —  the  Summary  TTY. 
Tc  the  extent  that  this  assumption  is  reasonable,  a  sinf?le 
voice  recognition  device  will  be  worKable.  Again,  it  may  be 
possible  that  the  convenience  offered  ty  voice  recognition 
flight  cause  the  procedures  themselves  to  be  mcdifiecL  so  that 
the  assumption  of  5  single  command  entry  position  would  be 
mere   realistic.   '.ve  raise  these  question  n-erely  tc  generate 
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ttoufcht  and  liscussicn  so  tfcat  they  end  any  other  questions 
that  rray  arise  tecause  of  tbe  installation  of  a  voice 
reccgniticn  syster  can  te  resolved  as  early  as  possible. 


C.  VCICZ  OUTPUT 
1 .   General 

With  voice  recognition,  there  were  really  no 
irrplerentat ion  issues  other  selection  of  the  best  equiprrent 
at  the  lowest  cost  and  the  need  for  careful  planning.  For 
this  reason,  we  focused  on  requirerrents  and  the  different 
capatilities  of  two  pcssitle  ASR  systerns.  When  we  turn  tc 
the  output  side,  we  encounter  a  different  prohletr.  With 
output,  the  requirements  are  simple  and  can  be  satisfied 
with  a  whole  range  of  relatively  inexpensive  products.  The 
protlerr  that  arises  concerns  the  way  that  a  voice  output 
device  Is  connected  to  the  CMCC.  As  we  noted  earlier,  voice 
output  is  software-intensive.  The  funda^-ental  design 
question,  then,  becones  one  of  where  tc  locate  this  software 
to  rrinirize  tne  cost  and  overall  impact.  We  are  interested 
less  in  particular  ccmtrercial  products  than  in  the  broader 
issue  of  irrplerrentation  strategy. 

There  are  cnly  twc  fundamer  :al  requirements  cf  a 
voice  output  system  in  the  CNCC.  First,  it  should  he 
capable  cf  producing  speech  output  from  prestcred  messages 
that  is  Intell  ig- i^le  to  someone  who  is  familiar  with  the 
output  vocabulary.   Second,  implementation  should  require  no 


rrajcr  software  cr  hardware  mcd  if  ica  tlcns  tc  the  existing 
CNCC,  and  preferably  none  at  all.  There  is  no  requireinent 
for  a  reai-tirre  text  to  si^eech  capaciiity.  Mor  is  there 
ever,  a  need  for  "hun^an  sounding"  speech.  A  voice  output 
alarm  would  te  in  addition  to  rather  than  a  replaceirent  for 
the  Logger  TTT.  Iven  if  the  voice  output  resseges  were  not 
perfectly  inteU  igifcle ,  the  systerr  would  still  te  at  least 
as  good  as  the  existing  one.  *e  do,  of  course,  want  to  get 
the  best  system  possible  within  sorre  cost  range;  it  can, 
however,  be  effective  even  if  voice  quality  is  not  the 
highest.  Voice  response  systenrs  are  available  on  the  narket 
for  prices  as  lew  as  S40t;  up  to  nrcre  than  $10,222,  with  most 
under  $5,202.  Eased  on  our  understanding  of  the  CNCC 
operation  and  our  experience  with  the  CNCC  rrodel,  we  see  no 
reason  to  go  above  the  riddle  range. 

We  will  consider  three  alternative  implep^entat  ion 
strategies.  They  differ  rrainly  in  th^  location  of  the 
text-speech  sottware  and  In  overall  flexibility. 

a.  The  voice  output  terminal  functions  cS  en 
unintelligent  peripheral  device  connected  directly  to 
the  CNCC  computer.  It  performs  no  computing  functions 
other  tnan  the  conversion  of  the  phonerre  strings  to 
output  speech. 

D.  The  voice  output  aevice  is  a  stand  alone  voice 
response   computer   that   would   accept   ASCII-ceded 
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cteracter  strings  from  tne  CNCC  and  iransforrr  therr   to 
voice  output  rressages. 

c.  The  synthesizer  is  a  slave  peripheral,  as  in  the  first 
strategy,  but  its  host  corrputer  is  not  the  CNCC  but  a 
gererai-purpcse  'nicrccciT'puter  that  wculd  handle  the 
text- speech  transformation  and  ether  computing 
functions. 

In  this  thesis  we  are  more  concerned  with  overall 
system  architecture  than  with  evaluating  specific  commercial 
products.  In  the  discussions  that  fellow,  however,  we  have 
found  it  necessary  to  establish  some  benchmarks  so  that  we 
can  ascriDe  approximate  costs  to  the  different  alternatives. 
For  the  first  and  third  alternatives,  our  benchmark  system 
is  the  VOTRAX  redel  SVA  synthesizer  manufactured  by  Federal 
Screw  Works  of  Troy  Michigan.  The  SVA  is  an  inproved 
version  cf  the  company's  popular  "Type- 'N-Talk"  text-tc- 
speech  converter.  Sotn  use  the  VOTRAX  SC-01  synthesizer 
chip,  tut  the  3VA  has  four  times  as  much  memory  and  better 
control  over  speech  inflection;  it  costs  about  %Z^^Wl.  The 
VCTHAX  ML-I,  which  we  used  in  the  C3  lac,  dees  not  seem  to 
provide  enough  extra  capability  to  warrant  its  ^10,000  price 
tag,  at  least  as  far  as  the  CNCC  application  is  concerned. 
For  the  second  option,  our  benchmark  system  is  the  SLC-II 
Intelligent  Ccmmunicat icns  Controller  manufactured  by 
Eigitai   Pathways  Inc.  of  Palo  Alto,  California.   The  SLC-II 
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is  a  siand   aicne   ccrrputer   with   voice   cuipui   capaDilit/ 
Duilt-in;  it  sells  for  about  ^3,i:00. 

2.   Slave  Voice  Output  Peripheral 

This  design  approach,  which  is  the  cne  used  for  the 
CNCC  rodel  at  NFS,  views  the  synthesizer  as  a  black-hox 
whose  sole  function  is  to  convert  phoneme  strings  output  by 
the  host  corrputer  into  intelligible  speech.  Figure  21  shows 
the  synthesizer  connectea  to  the  Logger  TTY  in  what  is 
referred  to  as  a  Shared  Channel  Configuration  (SSC). 
Alternatively,  if  there  were  a  sufficient  nurrber  of  serial 
interfaces,  the  synthesizer  and  the  logger  TTY  could  be  on 
separate  RS-23ZC  data  channels.  The  burden  of  somehow 
generating  the  phonere  strings  is  tome  by  tine  host 
computer,  in  this  case  the  CNCC.  'tie  should  note  that  the 
SVA  does  have  fairly  good  teit-to-speech  capability  that,  in 
theory,  would  '^ean  that  it  could  translate  the  existing 
logger  TTT  messages  directly  to  speech.  While  we  recognize 
this  possibility,  it  does  not  seem  that  this  alternative  is 
very  practical.  For  one  thing,  tex t-to-speect  algorithms 
are  not  perfect  and,  based  on  our  experience,  the  results 
will  probably  not  be  satisfactory.  English  is  net  regarded 
as  a  very  phonetic  language  ana  text-to-speech  synthesis  by 
rule  might  cause  the  word  "iMP"  to  be  pronounced  "Eye-Ti-p" 
or  the  word  LINE  to  come  out  as  "L-ee-n".  To  get  the 
necessary  control  ever  prcnunc  iat  ion  ,  the  phonerre  strings 
should  probably  be  prepared  in  advance.   Thus,   although   we 
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acicr.cwiedge  reaitin-e  lexi-ic-speech  conversicn  as  a 
possibility,  we  thinli  it  rrore  realistic  to  corsider  the 
Voorst  case,  i.e.  ^*here  the  CNCC  n^ust  output  the  phonerre 
strings . 

There  is  clearly  a  serious  drawback  to  this  approach 
in  that  It  requires  software  changes  in  the  CNCC.  It  is 
'*orth  considering,  however,  how  we  rright  irrpleirient  it  in 
such  a  way  as  to  minimize  the  amount  of  change  required. 
First  of  all,  the  crlgir.ai  teit-to-phonerre  conversion  should 
net  take  place  on  the  CNCC.  A  'ncdified  version  of  the 
conversion  prograrr  developen  at  NFS  could  be  run  on  a  COINS 
TAS  tc  produce  the  phcnerre  strings.  These  would  be  ^oved  to 
the  CNCC  and  stored  on  disK,  requiring  about  15,0  00  bytes  of 
cn-iine  storage.  The  CNCC  program  would  be  rrodified  to 
recognize  the  sit'^ations  wnen  a  voice  output  rressage  was 
required,  read  the  appropriate  phonere  strin*?  frcn"  disk,  and 
output  it  tc  the  synthesizer.  As  a  gross  estimate,  this 
would  require  at  least  500-1000  words  of  n-ain  rremory  for 
cede  and  cuffers. 

It  is  difficult  to  estimate  the  cost  of  the  CNCC 
software  changes,  or  whether  in  fact  they  can  even  be 
accorrplished .  Eased  on  experience,  however,  it  is  hard  to 
believe  that  the  cost  would  be  ruch  less  than  510,000, 
assuring  the  work  was  done  under  contract.  This  rears  that 
the  cost  of  this  option  would  be  at  least  $12,000  and  could 
very  possibly  be  higher.   About  the  only  real   advantage   to 
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the  approach  is  ihe  faci  ihat  we  can  use  ihe  leii-io-speech 
editcr  thai  we  leveicped.  at  NFS  with  only  slight 
FOdiricat ion.  In  that  case,  however,  the  host  corrputer  was 
considerably  mere  powerful  and  flexible  than  the  Kcneywell- 
31c.  All  in  all,  this  alternative  is  potentially  very 
costly  and  there  is  seme  risK;  that  it  can't  even  be  done  at 
all.  It  is  of  interest  rrore  for  acaderric  than  practical 
reasons . 

3 .   Stand  Alone  Voice  Response  Corrputer 

This  desii^n,  depicted  in  Figure  22,  elirrinates  the 
need  for  any  software  iroiif icat ions  to  the  CNCC  corrputer. 
Messages  would  be  sent  to  the  Logger  TTY  as  they  are 
currently  but  would  actually  be  reed  by  a  rri  crocorrputer  such 
as  the  Digital  Pathways  SIC-II.  This  corrputer  would  pass  on 
the  ressages  to  the  Logger  TTY  but  would  first  scan  them  to 
detect  those  that  should  have  an  associated  audio  response 
message.  ior  these,  the  nriicroprccesscr  wcuid  retrieve  and 
speaK  t^e  appropriate  output  message. 

The  SLC-II  is  a  microprocessor-based  communications 
controller  tnat  can  support  up  to  t  serial  I/o  channels. 
The  built-in  speecn  synthesizer  can  be  used  to  announce 
events  over  the  unit's  front  panel  spealier  or  via  the 
telephone.  It  is  usually  taught  the  details  of  a  specific 
application  oy  means  cf  simple  commands  to  its  own  cperating 
system  called  SAMSYN.  The  profile  of  the  application  is 
stored   in   battery-supported  memory   so   that,   after   the 
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iniiiai  training  session,  the  unit  can  be  considered  to  be  a 
'tiacK:  CC7'  tailored  for  a  specific  application.  Alon^  with 
the  basic  i;nit  ana  the  operating  sjsterr,  ihe  SIC-II  is 
equipped  with  a  version  ci"  micrcsol't  BASIC  to  extend  its 
software  capability.  The  SLC-II  uses  a  proprietary  bank- 
switching  technique  that  allows  it  to  access  up  to  e0K  bytes 
of  P.A^■  [Hef .  24:  p  .  I-l]  . 

The  SLC-II  would  te  interfaced  to  the  CNCC  computer 
ard  the  Logger  TTT  on  serial  RS-232  or  20  mA  channels. 
SArSYN  provides  the  capability  to  define  KITS  that  are  ASCII 
strings  that  the  SLC-II  Iooks  for  on  its  serial  line  from 
the  host.  Associated  ^ith  each  KEY  is  an  ACTION.  If  a  KZY 
is  aetected  in  the  rridst  of  the  serial  data  strearr  froif  the 
host,  it  irrredlateiy  triggers  aa  ACTION;  KEY  a  triggers 
ACTION  n.  ACTIONS  cause  particular  ircgrarrs  to  be  executed, 
i.e.  they  rray  dial  phone  nur^bers,  speak  sentences,  etc. 
Typically,  in  the  case  cf  the  CNCC,  the  action  wruli  involve 
speaking  a  sentence  such  as  "IMP  5  is  acwn."  Sentences  are 
corrposed  from  a  pre-stored  vocabulary. 

The  SLC-II  has  several  attractive  features.  Fully 
equipped,  with  60K  bytes  cf  memory  and  all  software,  it 
costs  ^3220.  Moreover,  it  requires  no  user  software  as 
such,  just  the  definition  of  KEYs ,  ACTIONS,  ard  SENTENCES 
vhich  can  be  aone  cy   someone  v*ho   is   not   an   experienced 
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programmer.   It  is  compact,  with  e  built  in  speaker,  and  its 
user  manual  is  clear  and  readable. 

There  are  tvc  potential  dravDaclcs.  i'irst  ,  the  voice 
vccabLlary  that  is  provided  is  not  defined  in  the  manual,  so 
there  is  no  way  of  Jcncwin^j  whether  or  net  it  is  adequate. 
The  vocabulary  requirements  of  the  CMCC  are,  to  be  sure, 
small,  tut  a  numter  of  unccmmcn  words  are  used.  It  is 
possible  that,  if  necessary,  an  extended  vocabulary  could  be 
purchased  at  seme  extra  cost.  Potentially  a  bigger  problem 
is  the  limited  number  of  XITs  and  ACTICN's,  currently  set  at 
16  each.  Fcr  the  model  at  NPS  we  used  only  12  basic 
sentences.  lach  had  a  number  of  variants,  however,  for  e.=>ch 
of  the  applicatle  network  components.  There  were  six 
variants  of  the  "if^P  dcwn"  message,  for  example,  one  for 
each  It^P  in  the  CCINS  subnetwork.  There  is  some  suggestion 
in  the  user's  nenual  that  tnese  limitations  mi^ht  be  deelt 
with  by  invoking  user-callable  subroutines  which  use  special 
ASCII  strings  called  buffers.  Buffers  seem  tc  provide  a  way 
to  formulate  an  speak  sentences  dynarically.  The 
comparatively  lew  ccst  and  the  ease  cf  implementation 
suggest  that  tnese  issues  should  be  investigated  further. 
4.   r^icrccompuier-CcatroUed  Synthesis 

This  architecture,  shown  in  figure  23,  is 
essentially  an  atterrpt  to  combine  the  advantages  of  the 
first  two  designs  while  minimizing  their  drawbacks.  It 
shares   with   the  first   the  advantage  cf  a  convenient  and 
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powerful  text-to-speech  editor  and,  with  the  secord  ,  the 
advantage  thai  no  changes  to  CNCC  software  are  required. 
Additionally,  it  is  more  flexible  than  the  second  approach 
because  it  rrakes  available  the  full  capabilities  of  a 
standard  general-purpose  operating  system. 

The  system  would  worK  in  the  following  way.  The 
user  would  employ  a  special  full-screen  editor  tc  generate 
the  phoneme  strings  to  drive  one  of  the  VOTRAX  speech 
synthesizers  such  as  the  SVA  described  above.  These  strirgs 
would  be  stored  in  standard  CP/M  text  files.  An  application 
program  running  under  the  CP/M  disk  operating  system  would 
capture  messages  sent  by  the  CNCC  and  pass  them  to  the 
logger  TTT.  It  would  also  scan  each  message  IccJsing  for 
alarm  conditions.  Once  the  program  recognized  an  alarm 
message,  it  would  retrieve  the  corresponding  phoneme  string 
and  send  it  to  the  SVA. 

A  speech  editor  that  could  be  used  to  support  this 
strategy  was  developed  ^^j  Psycho-Li  rgu  istic  Research 
Associates  of  ^■enlc  Park,  California  and  is  marketed  under 
under  the  trade  name  SpeechWizard .  SpeechWizard  is  a  full- 
screen editor  for  developing  phocerre  codes  for  the  entire 
family  of  VOTPAX  synthesizers.  It  is  not  a  text-to-speech 
program  but  rather  a  speecn  editor  tbat  generates  codes  for 
stored  vocabulary  tc  be  used  later  in  application  programs. 
In  that  sense  it  is  similar  to  the  mil  editor  developed  on 
UNIX  for  the  CNCC  rrodel.   It  can  be  run  on  any  micrcccTputer 


131 


that  STipports  ihe  CP/M  operating  systetr,  which  incliiles 
virtLaily  every  rrajor  personal  corrputer.  Using  a  special 
SCUNISPELLING  system,  the  user  can  generate  voice  messages 
without  learning  about  acoustic  and  articulatory  phonetics 
and  without  dealing  with  hexadecimal,  octal,  or  ASCII  codes. 
According  to  the  developer,  Dr.  Carol  A.  Simpson, 
SpeechWizard  has  been  tested  with  linguistically  naive  vsers 
who  have  used  it  to  create  intelligitle  speech  [Eef.  25]. 

SpeechWizard  is  being  used  at  NASA's  Ames  Research 
Center  to  support  a  research  effort  designed  to  assist 
helicopter  pilots  flying  low -altitude  missions.  The  system, 
installed  on  a  SCL-20  a0£0-based  microcomputer,  seems  easy 
to  use  and  the  output  speech,  produced  by  a  VOTRAX  ML-I ,  is 
clear  and  intelligible.  The  price  for  SpeechWizard  is  $325; 
of  course  to  use  it  requires  a  microcomputer  that  runs  the 
CP/f^  disk  operating  system.  The  cost  of  such  systems  will 
vary  but  a  fairly  well-equipped  system  can  be  purchased  for 
about  H,22e.  Assuring  that  we  used  the  VCTPAX  SVA 
synthesizer ,  the  total  cost  would  be  in  the  $6  ,000-$? ,000 
range. 

Impiementati en  of  this  alternative  would  also 
require  the  development  of  a  program  to  scan  the  CNCC 
messages  and  select  the  appropriate  voice  response  based  en 
the  contents.  This  program  can  oe  written  in  a  1- i^her-level 
language  and  snould  be  relatively  straightforward  since  it 
is   essentially   a  straight  character  string  match  and  table 
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iookLp.  Someone  fariliar  with  ibe  CNCC  ana  CP/M  should  be 
able  ic  develop  such  a  program  in  a  weeK  cr  less.  Although 
it  costs  a  little  rore  than  the  second  alternative,  this 
strategy  provides  a  good  deal  mere  flexibility  and 
possibility  for  enhancement.  The  number  of  possible  output 
messages  has  no  practical  limit  and  the  quality  of  the 
output  speech  is  good.  Since  SpeechWizard  was  developed  by 
a  professional  linguist,  it  embodies  a  considerable  amount 
of  linguistic  knowledge.  The  availability  of  a  programmable 
microcomputer  also  opens  up  other  possibilities.  The 
micrcccmputer  could,  for  example,  reformat  some  of  the  CNCC 
Summary  reports  to  improve  their  readability.  It  also  could 
perform  some  local  command  editing  and  provide  voice 
feedback  to  the  Network  Controller.  While  we  ere  not  really 
looking  for  a  way  to  improve  ether  aspects  cf  CNCC 
operation,  if  the  poss i oi lit ies  for  such  improvements  are 
presented,  it  would  seem  shortsighted  to  ignore  them. 

L.   COMBINED  VOICE  INPUT  AND  OUTPUT 

Although  voice  input  and  output  represent  t^^o 
independent  technclcgies,  it  is  natural  to  want  to  combine 
ther  in  <=  single  system.  In  several  pieces  i^.  this  thesis, 
we  have  alluded  to  a  clcsed-lccp  system  combining  speech 
recognition  and  voice  response.  Implementation  of  such  a 
system  would  net  be  easy,  particularly  In  view  of  the 
justifiable  reluctance  to  make  any  modifications  to  the  CNCC 
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scfiv.are.  Nevertheless,  a  siep  in  thai  directicr  plight  te 
possible  if  we  could  install  a  systeir  connected  to  the  CN'CC 
that  supported  tcth  speech  input  and  output  and  also  allowed 
for  the  developrrent  of  user  software  to  employ  them 
intell igentiy. 

The  Interstate  VCTEHM,  which  we  discvssed  above  in 
connection  with  voice  input,  provides  at  least  the 
pcssitility  to  construct  such  a  system  which  might  te 
configured  as  shown  in  Figure  24.  The  VOTEPr^  is  Z£0-based 
and  provides  4£a  bytes  of  HAM,  an  lee^-byte  flcppy-^isic 
drive,  a  ifeyboard  and  display  screen,  the  discrete-utterance 
Voice  Heco^Qltion  Module  (VHM),  and  voice  response  from  a 
500-wcrd  vocabulary  through  a  VOTRAX  SC-01  chip,  the  same 
one  used  in  the  SVA  synthesizer.  Ease  cost  for  the  system 
is  about  511,000,  56,000  for  the  VOTEl^M  itself  and  about 
55,000  for  a  wireless  transmitter;  an  expanded  model  mif?;ht 
cost  as  much  as  515,000.  This  is  in  contrast  to  a  cost  of 
over  520,000  if  we  used  a  T-600  speech  recognition  system 
with  a  microcompu t er-basei  voice  output  device.  As  we  noted 
above,  ve  don't  have  much  direct  experience  with  the 
Interstate  product  and  it  :^ay  come  up  short  en  some  of  the 
CNCC  requirements.  Its  100-u t terance  recognition 
vocabulary,  for  example,  may  not  be  adequate  for  CN'CC  use. 
The  ability  to  do  write  user  programs  in  high-level 
languages  may  provide  a  rreans  to  overcome  these  1  irritations. 
In  light  of  its  relatively  low   cost   and   in  view   of   the 
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Figure  £4.  CcTtined  Vcice  Inpul/Outpui  System 


functional  advantages  of  corrbining  input  and  output  a  single 
unit,  this  strategy  is  certainly  worth  pursuing  further. 
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VII.   ^U^^MARY  AND  CONCLUSIONS 

We  have  taicen  several  different  paths  in  the  preceding 
discussions;  it  seems  in  order,  therefore,  to  try  to  bring 
these  paths  together  and  surrrrarize  our  findings.  Ve  first 
developed  a  profile  of  coirmon  characteristics  of 
applications  that  have  successfiill/  used  voice  input.  The 
CNCC  application  scored  fairly  high  when  rratched  against 
this  profile.  In  a  less  fcrn-al  way,  ve  looked  at  typical 
applications  cf  voice  output  and  again  concluded  that  the 
CNCC  was  a  reasonable  canaidate  for  application  of  this 
technology. 

Having  established  the  potential  usefulness  of  voice 
technology  in  the  CNCC,  -e  proceeded  to  develop  a  computer 
rodel  that  would  help  us  evaluate  the  feasibility  of  VIO 
and,  at  the  same  time,  give  a  preliminary  indication  as  to 
the  ccntributicn  that  it  might  make  tc  the  overall 
effectiveness  of  the  Network  Controller  function.  Our 
conclusions  in  this  area  were  rather  tentative.  Ve  showed, 
for  example,  tbat  use  of  voice  technology  resulted  in  marked 
improvement  in  operator  response  time  for  cne  infernal  test 
that  compered  the  different  operating  environments.  This 
same  test  seemed  tc  suggest  that  the  use  cf  voice 
technology,  particularly  voice  output,  would  increase  the 
productivity   of   the  Network  Controller   in   performing 
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parallel  tasks.  Again,  cauticn  rrust  be  used  in  interpreting 
these  results  since  the  tests  were  informal,  unstructured, 
and  unrepl ica ted .  The  conclusion  with  regard  to  parallel- 
task  productivity,  in  particular,  must  be  viewed  es  the 
subjective  impression  of  a  single  test  subject  with  no 
quantitative  measure  to  support  it. 

The  appliccDi 1 ity  and  feasibility  established,  we  turned 
to  the  consideration  of  hew  best  to  integrate  the  technology 
into  the  existing  CNCC.  Installation  of  Speech  Recognition 
equipment  was  shewn  to  be  straight  forward,  involving  no 
changes  to  the  current  hardware  or  software  configuration. 
At  least  two  manufacturers  offer  systems  that  would  probably 
meet  the  needs  of  the  Network  Controller  function;  selection 
of  the  one  to  use  involves  the  classical  tradeoff  between 
cost  and  capability.  The  installation  of  a  voice  input 
device  would  necessitate  modification  to  some  of  the  current 
CNCC  operating  procedures.  As  with  any  change  to  an 
existing  operating  environment,  careful  planning  is 
essential  in  order  tc  maximize  the  benefits  and  minimize  the 
potential  disruption. 

The  probability  of  operational  disruption  is  much  lower 
for  voice  output.  The  addition  of  spoken  messages,  even  if 
the  speech  quality  is  not  too  high,  is  unlikely  to  hamper 
cperaticns.  The  most  serious  problem  with  voice  output,  at 
least  at  this  time,  is  that  it  requires  considerably  more 
software   than   does   speech   recognition.    To  implement  an 


eulio  response  capaDility  without  software  rroaif  icat  ions  to 
the  CNCC  will  require  that  the  voice  output  device  be 
driven  by  an  external  corrputer,  either  a  self-contained 
Voice  Response  Corrputer  or  a  general-purpose  rricrocorrputer. 
l»hichever  approach  is  chosen,  a  certain  amount  cf  software 
developrent  and  raintenance  will  he  required.  In  this 
context,  "software"  includes  anything  frcrn  crer'tion  anl 
editing  of  voice  tressages  to  developirent  of  sirple  prcgrains 
in  a  higher-level  language  like  BASIC.  The  tcey  point  is 
that,  while  we  ray  he  ahle  to  rrinirize  the  arrount  of 
software  work,  we  cannot  eliminate  it  all. 

In  the  section  on  irrplementation,  we  included  some 
discussion  of  the  comparative  costs  of  the  different 
alternatives.  This  is  a  difficult  area  to  suirmerize  since, 
as  right  be  expected,  the  cost  picture  is  a  comparatively 
fluid  one.  It  is  possible,  nonetheless,  to  at  least 
establish  some  cost  boundaries  as  guidelines  for  decision- 
making. At  the  lew  end,  it  is  possible  to  irplement  a 
combined  voice  input/output  system  for  as  little  as  $11,000? 
other  potential  configurations  could  cost  twice  that  much, 
and  there  are  a  number  of  alternatives  in  between.  Our 
investigation  has  shown  that  the  technology  can  improve 
operations  in  the  CNCC.  The  question  of  whether  or  not  the 
improvement  is  worth  the  cost  is,  quite  properly,  a 
management   rather   than  a  technical  one.   We  hope  that  seme 
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cf    the   grcundworfc     dene      in      this      thesis     nie^ht      rrake      that 
question    easier    to    en swer. 
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APPENDIX  A 
OPERATING  INSTRUCTIONS  EOR  CNCC  f^CDEL 

These  Insiruciions  assurre  ihat  ihe  person  who  wants  to 
run  the  model  has  a  working  I'aiPiliari  ty  with  Dcth  the  UNIX 
operating  systerr  and  the  CNCC  operating  procedures  as 
outlined  in  The  CNCC  Operators  Manual  [Reference  3].  Given 
these  assumptions,  running  the  rrodei  is  fairly 
straightforward.  The  process  involves  three  steps:  first, 
ensuring  that  the  support  files  contain  the  correct 
infcrnaticnj  second,  running  the  rrcdelj  and  third,  analyzing 
the  results. 

There  are  a  number  of  files  that  the  system  uses  to 
initialize  internal  parameters  and  tables.  The  casual  user 
will  only  ever  ha^e  to  make  changes  to  one  of  thetr,  the  file 
cncc.ini.  This  file  contains  a  nurrber  of  pareireters  <=nd 
switches  that  the  prograrr  uses  while  operating.  The  file  is 
a  standard  UNIX  text  file  that  can  be  modified  with  any  of 
the  text  editors,  such  as  the  fuil-screen  RAND  editor.  The 
file  also  contains  comments  that  assist  the  user  in  makir.g 
changes.  The  contents  of  the  file  as  used  at  NPS  are  as 
follows  : 


4b. 0 ,ee^0  0.2,c640  0.2 ,-1 ,/aev/ttyh 

rtmul  =  46.2     ;  nr  of  times  real  time  for  this  run 

imtbf  =  86420.0  ;  mtof  for  an  imp  in  sees 
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Irrttf  =  66400.0  ;  rrtbf  for  a  line  in  sees 
voflg  =  -1      ;  voice  ouiput  enatled 
logdev  =  /dev/xtyh  >*  device  for  voice  output 


The  pararr.eter  fields  contain  nurrbers  or  character 
strings  and  are  delimited  by  cormas;  the  format  is  fairly 
rigid  and  all  fields  except  the  last  rust  contain  the 
required  number  of  character  positions.  The  first  parameter 
^HTI^UL)  is  the  multiplication  factor  that  the  model  uses  to 
speed  up  real  time.  In  the  example,  each  half  hour  of 
program  time  would  correspond  to  an  entire  day  of  real  time. 
The  parameters  IMTBF  and  LMTB!  represent  the  MTBf  for  ir^Ps 
and  lines  respectively.  In  this  case,  mTEF  for  both  is  one 
day  ^£6,400  seconds).  The  program  will  apply  the  real  time 
multiplication  factor  to  these  values  converting  them,  in 
this  case,  tc  30  minutes  each.  The  parameter  VOFLG 
determines  whether  or  not  voice  output  messages  will  be 
used.  In  the  example,  the  value  cf  -1  turns  on  voice 
output;  to  disable  it,  the  user  would  change  the  value  to  0. 
The  last  field  contains  the  UNIX  path  name  for  the  device 
that  is  to  serve  as  the  Logger  TTY,  in  this  case  /dev/ttyh. 
This  provides  fleiiDility  in  configuring  the  system.  Note 
that  es  the  system  is  currently  aesigned,  the  voice  output 
device  and  the  Logger  TTY  rrust  be  the  same  terminal. 

Once  the  user  has  made  any  required  changes  to  cncc.ini, 
he  or  she  is  reaay  to  run  the  rr.odel.  To  do  this,  he  should 
LOGIN  on  both  the  Summary  and  Logger  TTYs  with  the  same 
USIEID   on  both  devices.   Next,  change  the  worlcing  directory 
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on  toth  lerminais  to  ihe  directory  vhere  the  software  for 
the  nodel  resides.  (At  NPS,  this  is  currently 
/usr/maiaricey/ccins . )  Next,  on  the  logger  tty,  enter  the 
corTrrand  'baci:';  this  will  start  up  a  background  process  that 
will  periodically  type  out  the  current  date  and  tirre.  Then, 
on  the  Surrmary  TTY,  enter  the  corrmand  'cncc'  and  the  rrodel 
will  start  to  execute.  The  prograr  will  first  type  out  the 
current  date  and  time  on  the  surmary  TTY  and  then  will  be 
ready  to  accept  con.rand  input.  The  following  corrrands  are 
currently  supported:  REPORT,  EROAECAST  FILE,  PRINT 
DIRECTORY,  PRINT  TOTAL,  SENT  LOCAL-FILE,  DU^P ,  PINA^'E  FILE, 
and  ZELETE  FILE.  See  the  CNCC  Operators  Manual  for  details. 
In  addition,  two  special  comrands  have  heen  included 
for  cperatcr  convenience.  It  may  te  usefiU  for  the  operator 
to  change  the  status  of  one  of  tbe  lines  in  the  network.  To 
do  this,  a  special  ccmrrand  has  teen  implemented.  The  user 
types  '?1';  the  system  responds  with  'INE  STATUS  IS';  the 
user  then  enters  either  a  'd',  a  'u'  or  an  'i'  to  denote 
that  the  line  is  either  down,  up,  or  looped?  the  system  then 
responds  'LINE:  '  and  the  user  enters  the  lire  number 
followed  by  an  escape  character.   Here  are  two  examples: 

71INE  STATUS  IS  uP   LINE:  2$ 
71INE  STATUS  IS  lOOPEL   LINE:  14? 

Typically  this  command  is  used  to  restore  a   line   that   has 

been   marked   down  by  some  network  event.   The  other  special 

command  provides  a  way  to  gracefully   stop   the-  model.    To 

143 


halt,   lype  '?q';  the  systeir  will  respond  'UIT  CONflRM  (T  OR 
N)'  and  the  user  responds  appropriately. 

After  running  the  model,  the  user  may  wish  to  examine 
the  response  times  for  the  run.  These  results  are  in  a  file 
named  cncc.log.  Each  line  in  the  file  corresponds  to  cne 
event  that  required  operator  action  and  contains  the  event 
code,  the  subcode,  and  the  number  of  seconds  that  elapsed 
between  the  time  that  the  failure  occurred  and  the  tine  that 
an  applicable  operator  response  was  noted. 
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APPENDIX  B 
PARAMETZRS  AND  GLOBAL  DATA  STRUCTURES 


1.  PARAMETER  DEFINITION'S 


pararneier 

perareier 
rararreter 
parameter 
parsrret  er 
pararreter 
paraTiet  er 
pe  rarreter 
parareter 
parareier 
parameter 
parareter 
parareter 
pa  rare ter 
jararreter 
parameter 
parameter 


evlsz  = 

maxev  = 
i  ev  e   = 
palsz  = 
Ipae   = 
Qiines  = 
nimps  = 
nhosts  = 
crrdtt/  = 
si;mtty  = 
disic 

lo^fli  = 
mail  = 
mien  = 
raw  = 
ccck  = 
nvmsg  = 


222 

^0 

4 

40 

4 

14 

5 

22 

5 

6 

1 

2 

14 

30 

"40 

"177737 
12 


size 
max  n 
iengt 
sz  cf 
Ingtfa 
nr  of 
nr  cf 
nr  of 
uni  t 
unit 
disk 
unit 
ipcf 
lengt 
mask 
mask 
nr  of 


of  event  Is 

r  of  events 

h  of  event 

pending  ac 

of  pal  ent 

lines  in  n 

irPS   in  n 

network  ho 

for  opr  cmd 

fcr  Summary 

i / 0  unit  nu 

#  for  log  f 

interrupt  s 

h  of  ipcf  m 

for  raw  tty 

for  cocked 

voice  outp 


entry 
ts  Ist 

ry 

etwc  rk 
etvcrk 
sts 
input 

rprpy 

mber 

ile 

ignal 

Sfo 

i/o 
tty 

I't   msgs 


2.  GLOBAL  DATA  STRUCTURES  (CChMCN  BLOCKS) 

CC^'MON  ELOCI  SVINi  contains  info  on  event  list 
common/evinf /ttne, tfne,rtmui,rtinv,event5,evlp,nev, 
*  stime.ctime.evccde.evprTis.evsupp 


int 
int 
rea 
rea 
byt 
int 
int 
int 
int 
byt 
tyt 
tyt 
equ 
tyt 


eger 
eger 
i  rtm 
1  rti 
e  eve 
eger 
eger 
eger 
eger 
e  eve 
e  evp 
e  sub 
ivale 
e  evs 


ttne 

tfne 

ul 

nv 

nts (ev 

evlp 

nev 

5 1  i-^e 

ctire 

ode 

rms 

col 

nee 

upp 


4) 
(S 


time  TILL  next  event 
time  FOR  next  event 
real  time  multiplier 
Inverse  of  rtmul  (l/rtmul) 
isz)      !  ordered  list  cf  events 

pointer  to  next  event  to  add 

nr  of  events  on  list 

pgm  starttiT'e 

current  time  (rel  to  stime) 

code  for  current  event 

subcode  cr  params  fcr  event 

utcod ,evprms (1 ) ) 

)         !  supplemer tary  event  information 
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CCrr^ON  BLOCK  NETINF  contains  tables  and  variables  that 
represent  the  current  state  of  the  network. 


ccmmon/netinf/  istat, 
+  i  r  1 1)  f  , 

b/te  istat  (nirrps) 
fcyte  Istat(nlines) 
byte  rrodlns  (4,  nlines) 
byte  vhirp( nhosts ) 
tyte  vhnam( 10, nhosts) 
real  irrtbf 
real  Irrtbf 


Istat  ,modln5  ,vhimp .vhnam, 

Irrtbf 

iiTp    status    tbi 
line   status    table 
network    topology    tbl 
host-irp   iT^apping   tbl 
virtual    host    narres 
MTEi    for    an    IMF 
MTBF    for   a   line 


COMMON  BLOCK  PALINF  contains 
common/pa linf/T)cl  ,pap,repeat 


info  on  pending  action  list 


fcyte  paKpalsz} 
integer  pap 
logical  repeat 


pending  actions  list 
pointer  fcr  pal 
true  when  we  are  repeating 
previous  events  frorr  pal 


COMMON  BLOCK  70C0UT  contains  info  on  voice  output  rrsgs 

corr,rT;on/vocout/voflg,logtty,vornr,vorrid,vorsg 

logical  vcflg  I  true  if  voice  output  turned 


on 


integer    logtty 
integer   vornr 
fcyte   vomid  (  2,  Dvrrsg) 
byte   vomsg(S ,  nvrrsg) 


unit    for   logger    tty 
message   ar  within   event 
code   and   message    nurrfcer 
file   narres  where   phonerre 
strings   are   stored 


COMMON   BLOCK   VDATA    contains    phoneme    info    for   current 

voice   output   message 

corrrron/vdata/vphon,infl,rate,DV 

integer*4  vphcn(maiv)  ! 

byte  infl(maxv),  rate(maxv)     ! 

byte  nv  ! 


phonemes  to  be 
inflection  and 
nr  of  phonemes 


output . 
ra  te 


COMMON  BLOCK  MISC  contains  general  purpose  stuff 
common/misc/adate,atime,lbuf,sttyfd,lttyfd,ttmode 

ascii  date 


byte  adate( 12) 
fcyte  atime(  8) 
byte  Ibufiaz) 

integer  sttyfd 
integer  Ittyfl 
integer  ttmode(3) 


asc  ii  t  ime 

scratch  buffer,  only  use  for 
temporary  storage  of  data, 
file  descr  for  summ  tty 
file  descr  for  logger  tty 
tty  modes 


COMMON  BLOCK  TTYINF  contains  global  data  structure  for 
command  handling  process 

ccmmon/ttyinf/  chan,ccode,delchr,Qellin,corplt 
integer  Chan  !  unix  chan  fcr  Summ  TTY 

integer  ccode  I  code  for  current  opr  cmd 
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icgicai  deichr 
logical  leilin 
logical  corrpli 


true  if  char  was  'delete  chr  ' 
true  if  char  was  'delete  line' 
true  if  corrmand  line  ccrrpleted 


CC^MCN  BLOCK  IPCF  ccntains  necessary  variables  and 
buffers  needed  to  irrplerrent  priritive  IPCF 
conron/ipcf/  rsg, rcvrsg,spid,dpid ,newmsg, norai 1 


byte  rr'sgimlen) 
byte  rcvirsg  (rrlen) 
integer  spid 
integer  dpid 
logical  newrsg 
logical  ncmail 


send  message  buffer 

receive  message  buffer 

sending  PID 

destination  PIE 

true  if  new  irsg  has  arrived. 

true  when  mail  ints  disabled 


COrMOM  BLOCK  ENVIR  contains  info  used  by  both  parent 

and  child  processes  in  CNCC  model.  Saved  in  disk  file 

envir .de  t . 

corrron/envi  r/ pa  rent ,  t  ty  in 

integer  parent  !  pid  for  CNCC  process 

integer  ttyin  !  pid  for  TTYIN  process 


TA3L2  OF  VALID  CPZEATCR  CO^•,^^ANDS 


parameter  ncmds  =  10 
byte  cmds(4 , ncras) 


cmdsd,  J) 
crrds(2.  j) 
crrds  (3  ,  j  ) 
cmds(4,j: 


nr  cf  chars 
1st  char  of 
2nd  char  of 
3rd    char    cf 


!  nr 
ta  cle 


of 
of 


in  Jth  command 
jth  command 
Jth  command 
jth  command 


opr  commends 
legal  ccmm.ands 


data 
data 
data 
data 
data 
data 
data 
data 
lata 
data 


(cmds 

[i,l), 

(cmdsl 

i,2)  , 

(cmds 

.1,3}, 

(cmds 

;i,4), 

(cmds 

i  5^ 

( cmds 

1  »  i^  ;  , 

(cm.ds 

U.v). 

(cmds ( 

1.8), 

(cmds( 

i,y} , 

(cmds 

.1,12) 

i  =  1,4)/1,  'B',0,0/ 

i  =  1,4)/1,  'P',e,0/ 

i  =  1,4)/1 ,  'S  ',£,?/ 

i  =  l,4)/k:,  'D'.  'U',0/ 

i  =  1,4)/3.'D','5','T'/ 

1  =  1,4)/3,'R','I','N'/ 

i  =  1,4)/3.'R','I'.'L'/ 

i  =  1,4)/3,'R','I','?'/ 

i  =  1,4)/1,  ';  ',0.e/ 

;,  i  =  1,4)/1.  'L',2,0/ 
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APPENDIX  C 
VOICE  INPUT  VOCABULART 


NR 

Z 
1 
2 

4 

c 

7 

a 

9 
12 

11 
12 
13 
14 
15 
16 
17 

16 

ly 

20 
21 

23 
24 
25 

26 
27 

2& 

2y 

3Z 
31 
32 
33 
34 

36 
37 

3a 

39 

40 


UTTERANCE 

ZERO 

ONE 

TWO 

THREE 

fOUR 

EIVI 

SIX 

SEVEN 

EIGHT 

NINE 

STOP  TEE  I^CDEL 

CUICKPRINT  REPORT 

STATUS REP 

TERUFUT  SUI^'MARY 

EAYSUrr 

DUrP 

rUMP 

II^P3 

I^P4 

IMP5 

irPc 

IMP2 
lrP3 

I^P4 

I^'Pt! 
irpe 

CRASH 

CRASH 

CRASH 

CRASH 

CRASH 

CRASH 
LINEl 
LINE2 


IMPl 

ir^pz 


EUrp 

DUMP 

DUMP 

DUMP 

RELOAD 

RELOAD 

RELOAD 

RELOAD 

RELOAD 

RELOAD 

CLEAR 

CLEAR 

CLEAR 

CLEAR 

CLEAR 

CLEAR 

^AR5 

MARK 

MARK 

MARK 

MARK 

MARK 

^ARK 


IMPl 
IMP2 
IMP3 
IMF4 
IMP5 
IMP6 


U? 
UP 
UP 
UP 

UP 
UP 

UP 


CORREC 


LINE3 

LIKEe 

LINE? 

LINE6 

LINE14 

CKSUh  IMPl 


OUTPUT  STRING 

0 

1 

2 

3 

4 
5 

6 
7 

8 
9 

?CT 

?REP; 

?REPS 

7REPT 

7REPD 

?DUIMPSYSe8$01$ 

?DUIMPSYSe8$02$ 

?DUIMPSYS8e^03$ 

?DUIMPSYS88$04$ 

7DUIMPSYS88$e5^ 

?DUiMPSYsee^0e$ 

?RELIMPSYSy9$01^ 

7RELIMPSYSyy$02$ 

7RELIMPSYS99$03? 

7RELlMPSYSy9$04$ 

?RELIMPSYSyy$05$ 

?RELIMPSYS99^06^ 

7BCLSARCRASH$1$ 

7RCLEARCRASE$2$ 

?5CLEARCRASK$3^ 

7ECLEARCRASH$4$ 

7SCLZARrHASE$5i 

7ECLEARCRASH^c^ 

?LU1^ 

7LU2$ 

7LU3$ 

VLU6^ 

7LU7$ 

?LU8^ 

7LU14^ 

7BHACMEM  IMP1$1$ 
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41 

42 
43 
44 

45 
46 
47 
48 
49 
52 
51 
52 

54 

56 
57 
56 
5S 
60 
61 
62 
63 
64 
65 
66 
67 

ee 

59 
70 
71 
72 
73 
74 
75 
76 
77 
76 
7y 
30 
61 
52 

«'^ 

84 
65 
86 


CCRRZCT  CKSUM  IMP2 

COPRECT  rKSUM  IMP3 

CORRECT  CKSUM  IMP4 

CORRECT  CKSUr'  IMP5 

CORRECT  CKSUM  IMP6 

SENT  LOCAL  jjILE 

riLETE  FILE 

RENAME 

PRINT  DIRECTORY 

HOV  MUCH  DISK  SPACE 

LOGFILS 

TOPOLOGY 

NCC 


IMP2^2$ 
IMP3$3$ 
IMP4<4$ 
IMP5^5$ 
IMP6^6^ 


SOLIS 

riA 

NSE 

CCINS  TAS 

ARPANET  GATEWAY 

TILE 

NDS 

BLACKER  FRONT  END 

BLACKER  TAS 

TTRF 

TESTHLE 

SCRATCHFILE 

IMP  1 

IMP  2 

IMP  3 

IMP  4 

IMP  5 

IMP  t 

LOGIN  TO  UNIX 

PASSWORD 

CHANGE  DIR  CCINS 

STARTUP  THE  NCC 

STOP  TEE  SYSTEM 

HOST  SUMMARY 

BROADCAST  FILE 

RELOAD 

MODEM  ZERO 

MODEM  ONE 

MODEM  T;»0 

NET  STATISTICS 

ESCAPE 

DELETE  CHARACTER 

CANCEL 

7BHACMEM 

7EHACMEM 

7BEACMEM 

7BHACMEM 

7BEACMEM 

7S 

7DEL 

7  REN 

7PD 

7PT 

CNCC.LOG^ 

CNCC  .NET$ 

1^ 
2$ 

4$ 

7^ 
8$ 

10 

13 

14 

19 

20 

TESTFILE$ 

SCRATCHFILE^ 

2$ 

3^ 
45 

5$ 

6$ 

MALARKEY<cr> 

<UNIX  PASSWD> 

CD  CCINS<cr) 

CNCC  ITEE  CHAT<cr: 

7CY 

7REPH: 

7B 

7  PEL 

0 
1 

2 

NFTSTATS 
<esc> 
<ctrl-h> 
^ctrl-u> 
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INTERNAL 

NUr^BER 

2101 

0321 

1001 

1002 

1003 

1101 

1201 

1401 

1501 

1601 

1801 

1802 

APPENDIX  r 
VOICE  OUTPUT  MESSAGES 


VOICE  MESSAGE 

IMP  ##  errors  corrected. 

IMP  #ff  has  been  reloaded. 

Line  ##  is  up. 

Line  ##  is  looped. 

Line   ##   is   dcvn. 

IMP   fta    is   down. 

Line   ##   is   down . 

IMP  ffft    cad   host    data   checksum 

IMP    ##    trap   condition. 

IMP   ##    crash    report . 

Line    ffff   is   down   plus    side. 

Line    ##    is   down    rrinus    side. 
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